基于OWASP的WEB應用安全檢測與防范

符泉麟

0 引言

隨著互聯(lián)網(wǎng)的發(fā)展，拉近了人與人之間的距離。不管相隔多遠，都能通過各種方式進行交流，人人都是互聯(lián)網(wǎng)的主角，就像人類社會一樣，為了使社會的安定就需要法律的制約，而互聯(lián)網(wǎng)也需要各種檢測和分析來保證其安全性。

不安全的WEB應用，已經(jīng)在破壞著我們生活中的各個方面。隨著數(shù)字化架構變得越來越復雜并相互關聯(lián)，實現(xiàn)應用程序安全的難度也呈指數(shù)級增加。要完全保證WEB應用的安全是沒有銀彈的，當你試圖思考安全掃描器或應用防火墻的時候，實際上不存在一下子就能解決WEB應用安全問題的方法，并且隨著軟件安全性與軟件的用戶友好性是成反比的。所以，必須找到一種檢測和分析方法，來找出企業(yè)組織所面臨的最嚴重的安全風險，同時提高人們對應用程序安全的關注度。

本文根據(jù)OWASP最新統(tǒng)計出的Top 5的WEB應用安全風險，對這些風險進行深入分析并提供檢測和預防手段，進而保證WEB應用的安全。

1 OWASP的簡介

OWASP(Open Web Application Security Project)是一個開放的、非盈利組織，致力于協(xié)助政府、企業(yè)開發(fā)升級的各類應用程序，以保證其可信任性。因為，沒有商業(yè)壓力，所以，能夠提供切實可行的、同時具有成本效益的應用安全信息。雖然OWASP 支持使用商業(yè)安全技術，但它不隸屬于任何技術公司。OWASP 基金會是一個確保項目長期成功的非盈利性實體。

2 WEB應用安全風險的發(fā)展歷史

互聯(lián)網(wǎng)應用程序所受到的威脅，隨著攻擊者和新技術的提升以及日益復雜的系統(tǒng)在不斷改變。為了跟隨前進的步伐，OWASP組織會每過幾年，對這TOP 10排行榜進行更新，更新情況，如表1所示：

表1 2007年版本和2010年最新版本的對比

從表1中可以看出，很多安全風險是長期存在的，所以，要對這些風險特別重視，還有些如惡意文件執(zhí)行，這個問題在很多環(huán)境中仍然是一個嚴重的問題。但是，其在2007年版本中提出的普遍性，由大量PHP應用程序問題而導致的。PHP現(xiàn)在已經(jīng)采用了更多默認的安全配置，從而降低了這個問題的嚴重程度。

3 WEB應用安全風險的檢測和分析

根據(jù)OWASP的安全性統(tǒng)計，以下將針對排名前5的風險，進行深入的分析與講解，并提供檢測和防范的方法。這5個風險，基本涵蓋了 Web應用安全方面百分之七十的問題，所以，掌握以下5點，對于提高Web應用安全性來說意義重大。

3.1 注入

注入攻擊漏洞，例如SQL，OS以及LDAP注入。這些攻擊，發(fā)生在不可信的數(shù)據(jù)作為命令或者查詢語句，被發(fā)送給解析器的時候。攻擊者發(fā)送的惡意數(shù)據(jù)，可以欺騙解釋器，以執(zhí)行計劃外的命令或者訪問未被授權的數(shù)據(jù)。如應用程序在存在漏洞的SQL語句的構造中，使用不可信數(shù)據(jù)：

攻擊者在瀏覽器中將“id”參數(shù)的值，修改成’or’1’=’1。這樣查詢語句的意義就變成了從數(shù)據(jù)庫 accounts表中返回所有的記錄，而不是只有目標客戶的信息。在最嚴重的情況下，攻擊者能夠使用這一漏洞，調用數(shù)據(jù)庫中特殊的儲存過程，從而達到完全接管數(shù)據(jù)庫。

檢測WEB應用是否存在注入漏洞的最好的辦法，就是確認所有解釋器的使用，都明確地將不可信數(shù)據(jù)從命令語句或查詢語句中區(qū)分出來。對于SQL調用，這就意味著在所有準備語句和儲存過程中使用綁定變量，并避免使用動態(tài)查詢語句。檢查應用程序是否安全使用解釋器的最快最有效的方法是代碼審查。代碼分析工具能幫助安全分析者，找到使用解釋器的代碼并追蹤應用的數(shù)據(jù)流。為執(zhí)行應用程序的自動動態(tài)掃描器提供一些信息，幫助確認一些注入漏洞是否存在。然而，掃描器并非總能達到解釋器每個分支，所以不容易檢測到一個攻擊是否成功。

防止注入漏洞，需要將不可信數(shù)據(jù)從命令及查詢中區(qū)分開。最佳選擇是使用安全的、完全避免使用解釋器或提供參數(shù)化界面的API。但要注意，有些參數(shù)化的API，如果使用不當，仍然會引入注入漏洞。如果沒法使用一個參數(shù)化的API，那么你應該使用解釋器的具體的escape語法來避免特殊字符。

3.2 跨站腳本(XSS)

當應用程序收到含有不可信的數(shù)據(jù)時，在沒有進行適當?shù)尿炞C和轉義的情況下，就將它發(fā)送給一個網(wǎng)頁游覽器，這就會產(chǎn)生跨站腳本攻擊。XSS允許攻擊者在受害者的游覽器上執(zhí)行腳本，從而劫持用戶會話，危害網(wǎng)站，或者將用戶轉向惡意網(wǎng)站。如應用程序在下面HTML代碼段的構造中，使用未經(jīng)驗證或轉義的不可信的數(shù)據(jù)：

攻擊者在瀏覽器中修改‘CC’參數(shù)為如下值：

這導致受害者訪問此頁面時，將會話ID發(fā)送到攻擊者的網(wǎng)站，使得攻擊者能劫持用戶當前會話。

檢查WEB應用是否有XSS漏洞，你需要確保發(fā)送給瀏覽器的所有用戶提供的輸入都是安全的。同時，你還需要確保用戶輸入在被顯示在頁面之前，都經(jīng)過了恰當?shù)霓D義。恰當?shù)妮敵鼍幋a，能確保這樣的輸入總是被視為瀏覽器中的文本，而不是可能被執(zhí)行的動態(tài)內容。使用專用工具都能自動找出一些跨站腳本漏洞。然而每一個應用程序使用不同的方式生成輸出頁面，并且使用不同的瀏覽器端解釋器，這使得自動檢測變得很困難。因此，要想達到全面覆蓋，必須使用一種結合的方式，在自動檢測的基礎上，同時采用人工代碼審核和手動滲透測試。

防止跨站腳本將不可信數(shù)據(jù)與動態(tài)的瀏覽器內容區(qū)分開。最好的辦法是，根據(jù)數(shù)據(jù)將要置于HTML的上下文中所有的不可信數(shù)據(jù)轉義。除非用戶界面框架已經(jīng)提供轉義，開發(fā)者需要在應用程序中提供轉義。

3.3 失效的身份認證和會話管理

與身份認證和會話管理相關的應用程序功能，往往得不到正確的實現(xiàn)，這就導致攻擊者破壞密碼、密鑰、會話令牌或攻擊其他的漏洞，去冒充其他用戶的身份。如：機票預訂應用程序支持URL重寫，把會話ID放在URL里：http://example.com/sale/saleitems;jsessionid=12345890GGGF SSDSDFS?dest=Shanghai

該網(wǎng)站一個經(jīng)過認證的用戶，希望讓他朋友知道這個機票打折信息。他將上面鏈接通過郵件發(fā)給他朋友們，并不知道自己已經(jīng)泄漏了自己的會話 ID。當他的朋友們使用上面的鏈接時，他們將可以使用他的會話和信用卡。

要檢查這類漏洞，就需要特別關注認證憑證和會話ID。當存儲認證憑證時，就需要多問自己幾個問題：是否總是使用hash或加密保護？認證憑證是否可猜測或者能夠通過薄弱的帳戶管理功能（例如賬戶創(chuàng)建、密碼修改、密碼恢復、弱會話ID）重寫？會話ID是否暴露在URL里？會話ID會超時嗎？成功注冊后,會話ID會輪轉？密碼、會話ID和其他認證憑據(jù)是否只通過TLS連接傳輸？

要防范這類漏洞，最好是讓開發(fā)人員采用一套成熟的認證和會話管理控制系統(tǒng)。如果是從新研發(fā)的話，那就需要一一檢查前面提出的問題。

3.4 不安全的直接對象引用

當開發(fā)人員暴露一個對內部實現(xiàn)對象的引用時，例如，一個文件，目錄或者數(shù)據(jù)庫密鑰，就會產(chǎn)生一個不安全的直接對象引用。在沒有訪問控制檢測或其他保護時，攻擊者會操控這些引用去訪問未授權數(shù)據(jù)。如應用程序在訪問帳戶信息的SQL調用中，使用未驗證數(shù)據(jù)。攻擊者能輕易在瀏覽器中輸入http://example.com/ account?acct=notmyacct然后可以將“acct”參數(shù)，修改成他所想要的任何賬戶號碼。如果應用程序沒有進行恰當?shù)尿炞C，攻擊者就能訪問任何用戶的賬戶。

檢測一個應用程序是否存在不安全的直接對象引用漏洞，最好的辦法，就是驗證其所有的對象引用，都具有適當?shù)姆烙芰ΑＲ_到這一目的，可以考慮對于資源的直接引用，應用程序需要驗證用戶有權限訪問他們所請求的具體資源。如果該引用是間接引用，那么應用程序需要保證該間接引用，只能映射到授權給當前用戶訪問的直接引用的值。

要防止不安全的直接對象引用，需要選擇一個適當?shù)姆椒▉肀Ｗo每一個用戶可訪問的對象，可以使用基于用戶或者會話的間接對象引用。這樣能防止攻擊者直接攻擊未授權資源。在服務器端，應用程序需要將每個用戶的間接引用映射到實際的數(shù)據(jù)庫關鍵字。還有任何來自不可信源的直接對象引用，都必須通過訪問控制檢測。

3.5 跨站請求偽造(CSRF)

一個跨站請求偽造攻擊，迫使登錄用戶的游覽器偽造的HTTP請求，包括該用戶的會話cookie和其他認證信息，發(fā)送到一個存在漏洞的WEB應用程序。這就允許了攻擊者迫使用戶游覽器，向存在漏洞的應用程序發(fā)送請求，而這些請求被應用程序認為是用戶的合法請求。如應用程序允許用戶提交不包含任何保密字段的狀態(tài)改變請求。

因此，攻擊者構建一個請求，用于將受害用戶賬戶中的現(xiàn)金轉移到自己賬戶。然后攻擊者在其控制的多個網(wǎng)站的圖片請求或iframe中嵌入這種攻擊。

如果受害用戶通過 example.com認證后，訪問任何一個這樣的惡意網(wǎng)站，偽造的請求將包含用戶的會話信息，導致該請求被授權執(zhí)行。

檢測應用程序是否存在該漏洞的最簡單的方法，就是確認是否每個鏈接都為每個用戶提供了不可預測的令牌。如果沒有這樣不可預測的令牌，攻擊者就能夠偽造惡意請求。重點關注那些調用能夠改變狀態(tài)的功能的鏈接，因為他們是跨站請求偽造攻擊的最重要的目標，還要注意會話、源 IP地址和其他瀏覽器自動發(fā)送的信息，不能作為防攻擊令牌，因為他們已經(jīng)包含在偽造的請求中。

要防止跨站請求偽造，需要在每個 HTTP請求的主體或者URL中，添加一個不可預測的令牌。這種令牌至少應該對每個用戶會話來說是唯一的，或者也可以對每個請求是唯一的。最好的方法是將獨有的令牌包含在一個隱藏字段中。這將使得該令牌通過HTTP請求主體發(fā)送，避免其被包含在URL中從而被暴露出來。

4 銀行ATM監(jiān)控項目實施安全檢測的效果

銀行ATM監(jiān)控是以監(jiān)控銀行ATM為中心，并提供遠程控制 ATM、產(chǎn)生流水和統(tǒng)計報表。在銀行實施此項目產(chǎn)品初期，銀行重金請了專業(yè)安全團隊來檢測該產(chǎn)品的安全性，但結果很不樂觀，為我們提出幾十條整改意見，如密碼采用MD5這種已被認為不安全的Hash算法、多處有注入漏洞、Struts，spring，hibernate的配置也有多處不合理并導致了部分URL訪問沒做限制等。這個結果，給我們公司敲響了警鐘。于是成立了專門的安全小組，并采用以上的WEB安全檢測和防范方法，對公司的每個項目進行自檢并對每個員工進行WEB應用安全知識講座。此后的項目中，客戶對我們產(chǎn)品的安全性非常的滿意。這不但提升了公司的形象，而且加強了公司整體的安全意識。

5 結束語

隨著Internet的發(fā)展，人們對WEB應用更為依賴，企業(yè)WEB應用安全性也變的越來越重要。正所謂安全第一，WEB應用用戶友好性很好，但如果安全充斥著安全漏洞，Server經(jīng)常被黑客攻擊，甚至用戶的個人私密信息遭暴露，這后果將是非常的嚴重。因此，企業(yè)或個人在創(chuàng)建WEB應用時，必需實時把安全放在第一，時時刻刻采用此方法來檢測和防范Web應用風險，并通過以下方法更好的杜絕風險，并做到防范于未然。

1)關注最新的安全技術動態(tài)，時時關注服務器，數(shù)據(jù)庫及操作系統(tǒng)等方面的漏洞，及時更新。

2)雖說安全風險的百分之七十涵蓋在此安全與檢測方法中，但其實還有百分之三十需要進一步的研究，來保證整個Web應用的萬無一失。

3)如果公司規(guī)模一般，那可以采用第三方的安全框架來保證WEB應用的安全。

4)如果公司對業(yè)務和安全的要求比較高，那需要有專業(yè)的安全小組來監(jiān)督開發(fā)，并加強員工的安全意識

[1]劉彬，SQL注入式攻擊分析，[j]電腦知識與技術，2009年04月

[2]肖云，基于Spring Security安全的Web應用開發(fā)，[j]計算機與現(xiàn)代化，2011年06月

[3]Russo,A.,Securing Timeout Instructions in Web Applications,[C]Computer Security Foundations Symposium,2009