OWASP 2010胡振宇：基于語義的WEB訪問安全檢測
【51CTO.com 獨家報道】OWASP 2010中國峰會已經圓滿結束了。那么在這個大會上，各個專家都做了精彩絕倫的演講。現在讓我們回顧一下胡振宇關于《基于語義的WEB訪問安全檢測》的相關報道吧。更多內容請關注：51CTO OWASP 2010中國峰會專題報道。
Validating web accessing with sematic constraints
胡振宇：基于語義的WEB訪問安全檢測。在這里面主要是技術知識。我們都在做技術方面的工作，今天我就和大家交流純技術方面的問題。
我今天給大家分享一下，大概分享下列幾個內容，第一個是簡單地一些攻擊和防范措施。第二個提一些思路，怎么從語義方面處理一些外部安全問題，再做一些語義檢測方面的算法，最后談談我們未來的發展。
我們先來簡要地回顧一下外部應用的體系結構，這些都是很清楚的，一般是分三個方面的架構，一個是瀏覽器，一個是WEB程序，還有一個加上后臺服務器，訪問是通過訪問器再到后臺的服務器再返回來以示范的形式展現出來。
典型的攻擊剛才第一個演講人講的，在澳大利亞第一位。現在這樣一個，在這邊有兩個，一個是名字的，一個是類型的。它的意思就是要查詢一個數據庫里面的信用卡的卡號。
那么對于一個合法的用戶來說，我們一般的情況下，依照頁面的要求來輸，比如在名詞里面輸1，在卡的類型里面輸2就行了，就出查出一個叫John人的帳號。所有的信用卡后都會查出來，最后一句盡管這樣解釋，這樣一般關健詞，后面的外語句，對于這些典型的攻擊我們有一些措施。一個方法就是過濾，把攻擊行為的關健詞提出來或者過濾較，把尖括號或者標簽，或者關掉，這是一個措施。
另外一個措施是轉譯，把典型的關鍵的字符轉換掉，替換。第三就是通過編碼，把原字符進行編碼轉換。這里面具體的意思我們不做解釋，因為時間有限。這些通常都出現過。出了哪些模式匹配以后，通過更嚴格的通過合法的檢查用戶是否合法。大家看用戶輸入的數據體現的位置，對于惡意的攻擊，他如果輸入了惡意的代碼這樣的一個區域以后，產生的語法是這樣的。這個語法數（音譯）和原始的差別很大了，你會發現不同構造，這是一個比較復雜的方法。
用語法檢查，這是一個簡單的頁面，比如你查《紅樓夢》，這個書的定價是50塊錢，左邊是頁面的原代碼，這里面有三個欲，這個隱藏欲輸入的價錢，真正的頁面顯示的50是后面的字符顯示的文本字符，當你輸入數量以后，網站根據你的數量自動乘以50，真正的語法結構你要輸入一個2，《紅樓夢》輸入以后出現一個2。一個惡意的攻擊者可能會篡改，你察看原代碼就可以把這個網頁篡改了，如果把隱藏篡改掉了，把50改成5，那這個最后語句就變了，我們看，這里不管是最后隱藏的欲是5還是50，那么生成的語法結構是一樣的，但是生成的語義是不一樣的。買了兩本書花了100塊錢，篡改了以后買了兩本書花了10塊錢，語義不一樣，單獨從語法來看不能解決問題。
現在呢，假如還是第一個問題，它的信用卡卡號的問題，在用戶名這里輸入John，但是他現在不輸入2，輸入1+1，這樣提交以后會產生什么樣的結果呢？提交以后解釋出來的是這樣的，大家看看后面多了一點，這個1+1提價到服務器有一個解釋，會自動算成二，從語法術的解析來看，這個語法術的結構也變化了。但是語義沒有變化。像剛開始那個女士講的，它是攻擊改變了原來語法器的意思，改了語義的結構。
所以說，我們就提出最終要通過語意安全，要接受什么樣的表達式我這個程序才能運行，但是語法關注這個程序怎么運行，所以我們認為安全問題根本上是語義的問題。如果你符合這個語義了，語義是安全的，否則就是不安全的。用戶輸入那些詞，經過一個變換，變換成可以被后臺的一些應用來接受的一些表達式，比方說，數據庫接受了語句，經過一個應用服務其把它變換一下。
那么我們說語義安全就是看經過應用程序變換以后的表達式它是不是符合應用開發人員最終設計的那個語意，如果符合了就語義安全了，否則就不安全。我們還是根據最根本的和程序到底做什么，結果來判斷它的行為。我們怎么做語義方面的東西呢，我們從這個結果知道，一個程序的語義，首先形成完整的語義必須語法合法，我們就可以通過程序的原理定義一個語法結構，一旦程序他總的來說表達式，這個程序它的語意最終是由語法結構來共同描述和形成的，我們就可以像描述語法結構那樣把語義描述出來。我們要考察這個程序的語義，我們就可以通過來約束語法術里的語義，更具體地說一點，我們需要把那些需要用戶復制的可變的借鑒，把他們的語意約束，整個程序的語意就被控制。
現在我們看，我們把這樣說了以后，把語法術里面用語義說出來，就變成了語義模板，我們在這邊把他們的語義在這個東西出現了，一個是漲停的數據，就可以限定它的語義。你用整合的約束的話，它的攻擊就不能夠得逞。比如剛才那個定單的例子說，我對里面隱藏的例子可以進行一個約束，限價是50，你不能改，你改了就不行。
這個等于每一個用戶的請求，最后轉化成請求，我們通過把用戶的請求變規范，從這里面來點擊看看他是不是符合，我們怎么做這個事情呢，我們可以通過下面幾個辦法第一個步驟，解析語法。語法出來把它最新的砍掉，把語義數進行對比，這就可以比他們是否可以同構，用戶完全可以被限定在語義里面，否則就出現語義偏差。如果真正從國際后臺做到解析語法可能比較復雜，我們可以通過前臺的輸入來進行一些校驗，形成用戶輸入的模板。這里面的頁面我們可以限定他的類型，他的值是《紅樓夢》不允許你修改，特別是最下面，用戶是隱藏看不見可能沒辦法操作，他通過修改原代碼的分析，這里面也要寫校驗，特別它限定的是50，這個就不能改，這個就可以防止頁面篡改的東西。簡單地說各種攻擊都可以防，表面修改或者pass攻擊，我們剛才說了，城市的攻擊是最終的語義的問題，這個能解決很多很多問題吧。
目前來說，我們要做這個工作，只是做了一些簡單的不完善的測試，還遇到了一些問題，這個問題遇到了以下幾個方面，一個是怎么建立語義模板，你可以經過審查原代碼解決，當然這是最好的辦法。當然你遇到比較大的這是不太理想的，你可以開發自動化，自動建立，自動建立到底建立得好與壞這個不能保證，我們提倡兩個碼結合，可以開發一些工具，最后去校驗。
我們下一步的工作把我們的技術進行更深入的評估，再發布，好了，我給大家交流的就是這些，謝謝大家。
【編輯推薦】
