發表文章

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

資安JAVA(二六): Code Review

圖片
來源: 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 會忽視無關安全性的錯誤。一般性和安全性議題的差別是檢查目的並非檢查方法。

資安JAVA(二五): Dynamic Analysis

圖片
來源: 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 弱點,^_^」,然後忽視靜態分析報告。但動態分析是針對已經上線的應用程式進行測試,當你發現營運中網站的弱點,其他人很難忽視實際上被攻擊的可能性。

資安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

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

資安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" 的資料。