發表文章

目前顯示的是 六月, 2012的文章

資安JAVA(二六): Code Review

圖片
來源:John Melton's Weblog
標題:YEAR OF SECURITY FOR JAVA – WEEK 26 – DO CODE REVIEWS
作者:John Melton
What is it and why should I care?

原始碼檢查( Code Review )源自單純的 Double Check 概念,讓其他人以系統化的方式找出錯誤。雖然步驟簡單,效果卻很好。研究 指出透過 Code Review 可以找出程式碼中 25-75%的錯誤,若結合其他品管方法,能達到更完美的程式碼。

雖然 Code Review 是開發者用來找出程式碼中所有錯誤,但本系列文章以資安為主,作者只會討論安全性議題。安全性 Code Review 會忽視無關安全性的錯誤。一般性和安全性議題的差別是檢查目的並非檢查方法。

資安JAVA(二五): Dynamic Analysis

圖片
來源:John Melton's Weblog
標題:YEAR OF SECURITY FOR JAVA – WEEK 25 – USE DYNAMIC ANALYSIS
作者:John Melton
What is it and why should I care?

動態分析就是分析執行中的程式。基本上,動態分析會自動執行應用程式,並進行分析。

動態分析當然不只限於應用程式的安全領域,還包括其他領域,但本篇文章將著重於安全領域。目前市面上的產品又稱為Dynamic Application Security Testing (or DAST)。

動態分析工具怎麼辦到的?Web應用程式安全的領域中,動態分析工具會模擬為使用者的瀏覽器,並送出具有攻擊目的 Request 給應用程式。不論攻擊是否成功,都能依據輸出結果,推論應用程式可能的弱點。以下是偵測 XSS 弱點的邏輯:
第一,瀏覽 Web 應用程式中的表單。
第二,填入javescript alert。
第三,送出表單。
第四,如果得到alert,則表單存在 XSS 弱點。

可以從這個簡單例子,看出動態分析工具的執行邏輯,而真正的動態分析工具可以做到更多測試。動態分析和靜態分析相反,他能提供攻擊行為真實可行的證據。做靜態分析時,開發者會以「其實我們有安全控制措施來防範 X 弱點,^_^」,然後忽視靜態分析報告。但動態分析是針對已經上線的應用程式進行測試,當你發現營運中網站的弱點,其他人很難忽視實際上被攻擊的可能性。


資安JAVA(二四): Static Analysis

圖片
來源: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。

資安JAVA(二三): HTTP Header Injection

圖片
來源:John Melton's Weblog
標題:YEAR OF SECURITY FOR JAVA – WEEK 23 – HTTP HEADER INJECTION
作者:John Melton
What is it and why should I care?

HTTP Header Injection 是一種影響 HTTP header 的特定注入攻擊方式。攻擊方式是透過操作 header 資料製造問題( response splitting, CRLF injection, cache poisoning, XSS, 等等)。這是個不被關注的問題,也比較少有針對性保護。

其中最常見的一種是 CRLF injection,CR 代表Carriage Return [%0d 或 \r] 、LF 代表 Line Feed [%0a 或 \n],攻擊方式是透過加入 CRLF 到 header 後造成伺服器以不安全的方式解讀response,而讓攻擊者可以控制被切斷的 response 。

資安JAVA(二二): HTTP Parameter Pollution

圖片
來源: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" 的資料。