Web Security Notes

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 26 – DO CODE REVIEWS 作者：John Melton Holmes: Found any bugs? Waston: You mean ...besides 5000 compiling errors? What is it and why should I care? 原始碼檢查(  Code Review  )源自單純的 Double Check 概念，讓其他人以系統化的方式找出錯誤。雖然步驟簡單，效果卻很好。 研究 指出透過 Code Review 可以找出程式碼中 25-75%的錯誤，若結合其他品管方法，能達到更完美的程式碼。 雖然 Code Review 是開發者用來找出程式碼中所有錯誤，但本系列文章以資安為主，作者只會討論安全性議題。安全性 Code Review 會忽視無關安全性的錯誤。一般性和安全性議題的差別是檢查目的並非檢查方法。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 25 – USE DYNAMIC ANALYSIS 作者：John Melton Opps !! You killed me. What is it and why should I care? 動態分析   就是 分析執行中的程式 。基本上，動態分析會自動執行應用程式，並進行分析。 動態分析當然不只限於應用程式的安全領域，還包括其他領域，但本篇文章將著重於安全領域。目前市面上的產品又稱為 Dynamic Application Security Testing (or DAST)。 動態分析工具怎麼辦到的？Web應用程式安全的領域中，動態分析工具會模擬為使用者的瀏覽器，並送出具有攻擊目的 Request 給應用程式。不論攻擊是否成功，都能依據輸出結果，推論 應用程式 可能的弱點。以下是偵測 XSS 弱點的邏輯： 第一，瀏覽 Web 應用程式中的表單。 第二，填入javescript alert。 第三，送出表單。 第四，如果得到alert，則表單存在 XSS 弱點。 可以從 這個簡單例子， 看出動態分析工具的執行邏輯，而真正的動態分析工具可以做到更多測試。動態分析和靜態分析相反，他能提供攻擊行為真實可行的證據。做 靜態分析時， 開發者會以「其實我們有安全控制措施來防範 X 弱點，^_^」，然後忽視靜態分析報告。但動態分析是針對已經上線的應用程式進行測試，當你發現營運中網站的弱點，其他人很難忽視實際上被攻擊的可能性。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 24 – USE STATIC ANALYSIS 作者：John Melton What is it and why should I care? 靜態分析(Static Analysis)是一種分析，能夠自動化檢查程式碼而不需要實際執行程式。靜態分析工具很多，可以達到的複雜度也不同 。作者大致介紹兩種類： Grep+ 和 資料流/控制流分析。 Grep+ Grep 是很棒的內文搜尋工具，但無法成為正式的靜態分析工具。以前人們認為總有一天可以用 Grep 發展出實用的靜態分析工具，但受限於只能搜尋符合某些特徵的程式碼，Grep 終究無法成為稱職工具 。Grep 能用在許多地方，但今日的靜態分析工具已經超越單純的內文搜尋工具。 資料流 / 控制流分析 Data/Control Flow Analysis 進階版的靜態分析工具所使用的技巧就是  資料流分析  和 控制流分析 。這種概念是從編譯器理論( Dragon book  )而來的，尤其是最佳化技術。雖然這不是新的概念，大家仍花了很多心力才 應用到靜態分析 。 一般而言，這些工具會建立應用程式的資料結構模型(又稱抽象語法樹 Abstract Syntax Tree)，然後以不同方法遍歷抽象語法樹( AST )的結構，找出問題。 其實開發者最熟悉的 IDE 工具已經再利用上述的概念，當你寫程式時， IDE 會建立靜態的抽象語法樹，並即時顯示 警告和 錯誤。某些 IDE 工具甚至會從程式外部，檢查 AST 的安全性。 註：雖然靜態分析並不只是針對安全領域，但身為資安專家的作者自然是以安全為主。作者提醒大家，不只資安，靜態分析也可以解決其他問題。而目前資安市場中相關的產品又稱為 Static Application Security Test。

無法查看此摘要。請 按這裡查看文章。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 22 – HTTP PARAMETER POLLUTION 作者：John Melton What is it and why should I care? HTTP 參數汙染是一種自訂字串語句然後複寫 HTTP GET/POST 參數的注入技術。2009年的一篇 文章  提出這個名詞後，逐漸普及。只要你能發揮創意填補HTTP的參數，多次送出相同的參數，就有機會造成WEB應用程式出乎意料的反應。如果有人利用這個request /mypage.jsp?query=abc&acct=4 改成這樣，會發生什麼事呢？ /mypage.jsp?query=abc&acct=5&acct=4 當你呼叫 request.getParameter("acct") 會得到什麼值？不同的 server 會有不同的反應，還好，這裡有一份 PPT 可以讓你參考各家 server 的反應。JAVA 的朋友們，你通常會得到相同參數的第一個值─也就是  request.getParameter("acct") = "5"。 所以勒？有這麼嚴重嗎？是的，這個弱點會產生複寫參數、修改行為、存取變數、繞過輸入驗證等等的漏洞。 作者認為這和HTTP 路徑參數問題(Http Path Parameter Issue)  很像，共同點是你可以自訂授權檢查的 URL 後面的參數，然後 request 到不一樣的值。上面的例子進行授權檢查時，"acct" 變數可能得到 "4" ，然後使用者將被認定是 acct=4 的身分。然而，實際上你的資料庫收到的  request.getParameter("acct") 卻是帳號 "5" ，所以使用者 "4" 就可以繞過授權檢查存取使用者 "5" 的資料。