Web安全測試——常見的威脅攻防

• SQL注入

 

部分程序員在編寫代碼的時候，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶能夠提交一段數據庫查詢代碼，根據程序返回的結果，得到某些他想得知的數據，這就是所謂的SQL Injection，即SQL注入

案例

HTTP://xxx.xxx.xxx/abc.asp?p=YY

①HTTP://xxx.xxx.xxx/abc.asp?p=YY’(附加一個單引號), abc.asp運行異常,表示沒有對特殊字符進行轉義或過濾

②HTTP://xxx.xxx.xxx/abc.asp?p=YY and 1=1, abc.asp運行正常，並且與HTTP://xxx.xxx.xxx/abc.asp?p=YY運行結果相同；

③HTTP://xxx.xxx.xxx/abc.asp?p=YY and 1=2, abc.asp運行異常；

若是以上三步全面知足，abc.asp中必定存在SQL注入漏洞。

攻擊步驟

一、  發現SQL注入位置；

二、  判斷後臺數據庫類型；

三、  肯定XP_CMDSHELL可執行狀況

四、  發現WEB虛擬目錄

五、  上傳木馬；

六、  獲得管理員權限；

具體見：http://www.cnblogs.com/tanshuicai/archive/2010/02/03/1664900.html

常見的不安全寫法：

Statement s = connection.createStatement(); 

ResultSet rs = s.executeQuery("SELECT email FROM member WHERE name = " + formField);

安全寫法

PreparedStatement ps = connection.prepareStatement(

    "SELECT email FROM member WHERE name = ?"); 

ps.setString(1, formField);

ResultSet rs = ps.executeQuery();

如何防護？

轉義？過濾？

避開過濾方法

一、大小寫變種

若小寫被過濾，則變成大寫繼續執行

http://bbs.ichunqiu.com/data/attachment/forum/201608/21/134905u36phck612j6kw3j.gif?_=5793686

二、URL編碼

雙url編碼能夠繞過過濾

http://bbs.ichunqiu.com/data/attachment/forum/201608/21/143646fnygion74g9c8idi.gif?_=5793686

三、SQL註釋

不少開發人員認爲，將輸入限制爲單個就能夠限制SQL注入攻擊，因此他們每每就只是阻止各類空白符，可是內聯註釋不使用空格就能夠構造任意複雜的SQL語句。

http://bbs.ichunqiu.com/data/attachment/forum/201608/21/142321um0h0q5zefvhooqk.gif?_=5793686

防護

輸入驗證是指要驗證全部應用程序接收到的輸入是否合法。

有兩中不一樣類型的輸入驗證方法：白名單和黑名單驗證

白名單驗證：好比id值，那麼咱們判斷它是否爲數字。

黑名單驗證：使用正則表達式禁止使用某些字符和字符串

應該儘可能使用白名單，對於沒法使用白名單的，使用黑名單提供局部限制。

 

• 跨站腳本（XSS）

跨站腳本（cross site script）爲了不與樣式css混淆，因此簡稱爲XSS。

什麼是XSS？

XSS是指攻擊者利用網站沒有對用戶提交數據進行轉義處理或者過濾不足的缺點，進而添加一些代碼，嵌入到web頁面中去。使別的用戶訪問都會執行相應的嵌入代碼。從而盜取用戶資料、利用用戶身份進行某種動做或者對訪問者進行病毒侵害的一種攻擊方式。

反射型xss攻擊

通常會放在請求或者跳轉的連接中，一次性形成攻擊。，稱之爲反射性XSS攻擊

例：頁面搜索框輸入"/><script>alert("這是一個反射型xss攻擊")</script>後點擊搜索，會提示提示框

 

存儲式XSS攻擊

通常是在提交表單式的請求中，注入XSS，存入服務器中，達到攻擊打開的用戶，影響全部看到的人。

例：新建用戶，描述中輸入"/><script>alert("這是一個存儲型xss攻擊")</script>

保存後，後面的用戶打開用戶管理頁面，查看到剛添加的用戶所在頁，都會彈出提示框

 

 

防護

1. 前端在顯示服務端數據時候，不只是標籤內容須要過濾、轉義，屬性值也可能須要。

1)     將重要的cookie標記爲http only, 這樣的話Javascript 中的document.cookie語句就不能獲取到cookie了。

2)     表單數據規定值的類型，例如：年齡應爲只能爲int、name只能爲字母數字組合。。。

3)     對數據進行Html Encode 處理

4)     過濾或移除特殊的Html標籤，例如: <script>, <iframe> , &lt; for <, &gt; for >, &quot for

5)     過濾JavaScript 事件的標籤。例如 "onclick=", "onfocus" 等等。

2. 後端接收請求時，驗證請求是否爲攻擊請求，攻擊則屏蔽。

【特別注意】

在有些應用中是容許html標籤出現的，如輸出須要html代碼、javascript代碼拼接、或者此表單直接容許使用等等，須要區別處理。

 

• 跨站請求僞造（CSRF）

CSRF(Cross-site request forgery), 就是攻擊者盜用你的身份，以你的名義發送惡意請求。

攻擊原理

如圖所示，其中Web A爲存在CSRF漏洞的網站，Web B爲攻擊者構建的惡意網站，User C爲Web A網站的合法用戶。

 

一、用戶C打開瀏覽器，訪問網站A，輸入用戶名和密碼請求登陸網站A;

二、在用戶信息經過驗證後，網站A產生Cookie信息並返回給瀏覽器，此時用戶登陸網站A成功，能夠正常發送請求到網站A;

三、用戶未退出網站A以前，在同一瀏覽器中，打開一個TAB頁訪問網站B;

四、網站B接收到用戶請求後，返回一些攻擊性代碼，併發出一個請求要求訪問站點A;

五、瀏覽器在接收到這些攻擊性代碼後，根據網站B的請求，在用戶不知情的狀況下攜帶Cookie信息，向網站A發出請求。網站A並不知道該請求實際上是由B發起的，因此會根據用戶C的Cookie信息以C的權限處理該請求，致使來自網站B的惡意代碼被執行。

CSRF攻擊是源於WEB的隱式身份驗證機制！WEB的身份驗證機制雖然能夠保證一個請求是來自於某個用戶的瀏覽器，但卻沒法保證該請求是用戶批准發送的！

案例

銀行網站A，它以GET請求來完成銀行轉帳的操做，如：

http://www.mybank.com/Transfer.php?toBankId=11&money=1000

危險網站B，它裏面有一段HTML的代碼以下：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先，你登陸了銀行網站A，而後訪問危險網站B，這時你會發現你的銀行帳戶少了1000塊......

　　爲何會這樣呢？緣由是銀行網站A使用GET請求更新資源。在訪問危險網站B的以前，你已經登陸了銀行網站A，而B中的<img>以GET的方式請求第三方資源（這裏的第三方就是指銀行網站了，本來這是一個合法的請求，但這裏被不法分子利用了），因此你的瀏覽器會帶上你的銀行網站A的Cookie發出Get請求，去獲取資源「http://www.mybank.com/Transfer.php?toBankId=11&money=1000」，結果銀行網站服務器收到請求後，認爲這是一個更新資源操做（轉帳操做），因此就馬上進行轉帳操做......

防護

優先考慮的就是利用已有的CSRF防禦方案。許多框架，如Spring, Play, Django以及AngularJS，都內嵌了CSRF防禦，一些web開發語言如.Net也提供了相似的防禦，OWASP CSRF Guard對Java應用提供了CSRF防禦。不然須要在每一個HTTP請求中添加一個不可預測的令牌，這種令牌至少應該對每個用戶會話來講是惟一的。

一、  服務器端驗證HTTP Referer字段

根據HTTP協議，在HTTP頭中有一個字段叫Referer，記錄了該HTTP請求的來源地址。訪問一個安全受限頁面的請求必須來自於同一個網站。好比某銀行的轉帳是經過用戶訪問http://bank.test/test?page=10&userID=101&money=10000頁面完成，用戶必須先登陸bank.test，而後經過點擊頁面上的按鈕來觸發轉帳事件。當用戶提交請求時，該轉帳請求的Referer值就會是轉帳按鈕所在頁面的URL(本例中，一般是以bank. test域名開頭的地址)。而若是攻擊者要對銀行網站實施CSRF攻擊，他只能在本身的網站構造請求，當用戶經過攻擊者的網站發送請求到銀行時，該請求的Referer是指向攻擊者的網站。所以，要防護CSRF攻擊，銀行網站只須要對於每個轉帳請求驗證其Referer值，若是是以bank. test開頭的域名，則說明該請求是來自銀行網站本身的請求，是合法的。若是Referer是其餘網站的話，就有多是CSRF攻擊，則拒絕該請求。

二、  在請求地址中添加token並驗證或驗證碼

CSRF攻擊之因此可以成功，是由於攻擊者能夠僞造用戶的請求，該請求中全部的用戶驗證信息都存在於Cookie中，所以攻擊者能夠在不知道這些驗證信息的狀況下直接利用用戶本身的Cookie來經過安全驗證。由此可知，抵禦CSRF攻擊的關鍵在於：在請求中放入攻擊者所不能僞造的信息，而且該信息不存在於Cookie之中。鑑於此，系統開發者能夠在HTTP請求中以參數的形式加入一個隨機產生的token，並在服務器端創建一個攔截器來驗證這個token，若是請求中沒有token或者token內容不正確，則認爲多是CSRF攻擊而拒絕該請求。

三、  考慮對全部cookie使用」SameSite」標籤，該標籤逐漸被各種瀏覽器所支持。

防止 CSRF 攻擊的辦法已經有 CSRF token 校驗和 Referer 請求頭校驗。爲了從源頭上解決這個問題，Google 起草了 一份草案 來改進 HTTP 協議，那就是爲 Set-Cookie 響應頭新增 SameSite 屬性，它用來標明這個 cookie 是個「同站 cookie」，同站 cookie 只能做爲第一方 cookie，不能做爲第三方 cookie。

參考：http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html

 

 

• 失效的認證和會話管理

身份認證

最多見的是登陸功能，每每是提交用戶名和密碼，在安全性要求更高的狀況下，有防止密碼暴力破解的驗證碼，基於客戶端的證書，物理口令卡等。

會話管理

HTTP自己是無狀態的，利用會話管理機制來實現鏈接識別。

身份認證的結果每每是得到一個令牌，一般放在cookie中，如jsessionid。以後對用戶身份的識別根據這個受權的令牌進行識別，而不須要每次都要登陸。

 

• 失效的認證和會話管理

開發者一般會創建自定義的認證和會話管理方案。但要正確實現這些方案卻很難，結果這些自定義的方案每每在以下方面存在漏洞：退出、密碼管理、超時、記住我、祕密問題、賬戶更新等等

案例

一、機票預訂應用程序支持URL重寫，把會話ID放在URL裏：

http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii

該網站一個通過認證的用戶但願讓他朋友知道這個機票打折信息。他將上面連接經過郵件發給他朋友們，並不知道本身已經泄漏了本身的會話ID。當他的朋友們使用上面的連接時，他們將會使用他的會話和信用卡。

二、應用程序超時設置不當。用戶使用公共計算機訪問網站。離開時，該用戶沒有點擊退出，而是直接關閉瀏覽器。攻擊者在一個小時後能使用相同瀏覽器經過身份認證。鹽

三、攻擊者進入系統的數據庫。存儲在數據庫中的用戶密碼沒有被哈希和加鹽, 全部用戶的密碼都被攻擊者得到。

 

如何驗證程序是否存在失效的認證和會話管理？

最須要要保護的數據是認證憑證(credentials) 和會話ID。

一、當存儲認證憑證時，是否老是使用hashing或加密保護嗎?

二、認證憑證是否可猜想，或者可以經過薄弱的的賬戶管理功能（例如帳戶建立、密碼修改、密碼恢復, 弱會話ID）重寫？

三、會話ID是否暴露在URL裏(例如, URL重寫) ？

四、會話ID是否容易受到會話固定(session fixation) 的攻擊?

五、會話ID會超時嗎? 用戶能退出嗎?

六、成功註冊後,會話ID會輪轉嗎?

七、密碼、會話ID和其餘認證憑據是否只經過TLS鏈接傳輸？

防護

一、區分公共區域和受限區域

站點的公共區域容許任何用戶進行匿名訪問。受限區域只能接受特定用戶的訪問，並且用戶必須經過站點的身份驗證。

二、對最終用戶賬戶使用賬戶鎖定策略

當最終用戶賬戶幾回登陸嘗試失敗後，能夠禁用該賬戶或將事件寫入日誌。　

三、支持密碼有效期

　　密碼不該固定不變，而應做爲常規密碼維護的一部分，經過設置密碼有效期對密碼進行更改。在應用程序設計階段，應該考慮提供這種類型的功能。

四、可以禁用或鎖定賬戶

若是在系統受到威脅時使憑證失效或禁用賬戶，則能夠避免遭受進一步的攻擊。

五、不要在用戶存儲中存儲密碼

　　若是必須驗證密碼，則沒有必要實際存儲密碼。相反，能夠存儲一個單向哈希值，而後使用用戶所提供的密碼從新計算哈希值。爲減小對用戶存儲的詞典攻擊威脅，可使用強密碼，並將隨機 salt 值與該密碼結合使用。

六、要求使用強密碼

　　要求輸入至少 8 位字符，其中要包含大寫字母、小寫字母、數字和特殊字符。不管是使用平臺實施密碼驗證仍是開發本身的驗證策略，此步驟在對付粗暴攻擊時都是必需的。在粗暴攻擊中，攻擊者試圖經過系統的試錯法來破解密碼。使用常規表達式協助強密碼驗證。

七、不要在網絡上以純文本形式發送密碼

　　以純文本形式在網絡上發送的密碼容易被竊聽。應加密傳輸。

八、保護身份驗證 Cookie

　　身份驗證 cookie 被竊取意味着登陸被竊取。能夠經過加密和安全的通訊通道來保護驗證票證。另外，還應限制驗證票證的有效期，以防止因重複攻擊致使的欺騙威脅。

　　不要經過 HTTP 鏈接傳遞身份驗證 cookie。在受權 cookie 內設置安全的 cookie 屬性，以便指示瀏覽器只經過 HTTPS 鏈接向服務器傳回 cookie。

九、對身份驗證 cookie 的內容進行加密

　　即便使用 SSL，也要對 cookie 內容進行加密。若是攻擊者試圖利用XSS攻擊竊取 cookie，這種方法能夠防止攻擊者查看和修改該 cookie。在這種狀況下，攻擊者仍然可使用 cookie 訪問應用程序，但只有當 cookie 有效時，才能訪問成功。

十、限制會話壽命

　　縮短會話壽命能夠下降會話劫持和重複攻擊的風險。會話壽命越短，攻擊者捕獲會話 cookie 並利用它訪問應用程序的時間越有限。

 

 

• 失效的訪問控制

當生成web頁面時，數據、應用程序和APIs常用對象的實名或關鍵字。功能、URLs和函數名稱常常容易被猜解。而應用程序和APIs並不老是驗證用戶對目標資源的訪問受權，如普通用戶能夠訪問管理員的頁面，這就致使了訪問控制失效。測試者能輕易操做參數值以檢測該漏洞。代碼分析能很快顯示應用程序是否進行了正確的權限驗證。

攻擊

猜一些頁面的url，進行攻擊。

案例

管理員頁面並無菜單管理的權限，可是卻能夠在瀏覽器中輸入菜單管理的url:menu來訪問菜單管理頁面

防護

一、檢查訪問。任何來自不可信源的直接對象引用都必須經過訪問控制檢測，確保該用戶對請求的對象有訪問權限。

二、使用基於用戶或者會話的間接對象引用。這樣能防止攻擊者直接攻擊未受權資源。例如，一個下拉列表包含6個受權給當前用戶的資源，它可使用數字1-6來指示哪一個是用戶選擇的值，而不是使用資源的數據庫關鍵字來表示。OWASP的ESAPI包含了兩種序列和隨機訪問引用映射，開發人員能夠用來消除直接對象引用。

三、自動化驗證。利用自動化驗證正確的受權部署。這是一般作法。

 

• 安全配置錯誤

沒有正確的安全配置，致使外部的匿名攻擊者和擁有賬戶的內部用戶均可能會試圖破壞系統

攻擊

攻擊者訪問默認帳戶，無效頁面，沒打補丁的漏洞，未受保護的文件及文件夾等，以得到未受權的訪問或對應用系統進行了解和分析。

案例

一、服務器管理員控制檯自動安裝後沒有被刪除。而默認賬戶也沒有被改變。攻擊者在你的服務器上發現了標準的管理員頁面，經過默認密碼登陸，從而接管了你的服務器。

二、目錄列表在你的服務器上未被禁用。攻擊者發現只需列出目錄，她就能夠找到你服務器上的任意文件。攻擊者找到並下載全部已編譯的Java類，經過反編譯得到了全部你的自定義代碼。而後，她在你的應用程序中找到一個訪問控制的嚴重漏洞。

三、應用服務器配置容許堆棧跟蹤信息返回給用戶，這樣就暴露了潛在的漏洞。如已知的有漏洞的框架版本。

四、應用服務器自帶的示例應用程序沒有從您的生產服務器中刪除。該示例應用有已知安全漏洞，攻擊者能夠利用這些漏洞破壞您的服務器。

防護

一、 配置全部的安全機制

二、 關掉全部不使用的服務和服務器上的示例應用程序

三、 設置角色賬號權限

四、 使用日誌和警報

五、 全部錯誤只顯示友好信息，不顯示任何與實際錯誤相關的信息

六、 及時更新服務器補丁

 

 

• 敏感信息泄漏

攻擊

經過SQL注入或命令執行或直接使用腳本進行爬蟲，來得到用戶的帳號密碼、實名信息泄露、行爲記錄等

防護

一、預測一些威脅（好比內部攻擊和外部用戶），加密這些數據的存儲以確保免受這些威脅。

二、對於不必存放的、重要的敏感數據，應當儘快清除。

三、確保使用了合適的強大的標準算法和強大的密匙，而且密匙管理到位。

四、確保使用密碼專用算法存儲密碼

五、禁用自動完成防止敏感數據收集，禁用包含敏感數據的緩存頁面。

六、加密傳輸

七、使用安全的加密算法