一、Web安全漏洞：
1、跨站腳本攻擊XSS：Cross Site Scripting，為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站腳本攻擊縮寫為XSS
惡意攻擊者往Web頁面里插入惡意script代碼，當用戶瀏覽該頁面時，嵌入其中Web里面的Script代碼會被執行，從而達到惡意攻擊用戶的目的。在不同場景下，XSS有相應不同的表現形式，主要分為反射型、存儲型、DOM型的跨站腳本攻擊，所造成的映像主要是竊取用戶的登錄憑證（Cookies）、掛馬攻擊、頁面訪問挾持等
手工測試：
1.1、反射型XSS測試：（相當於get請求頁面：url里面輸入）對提交頁面的各個參數依次進行SQL注入測試，判定是否存在注入
比如正常訪問的地址是 http://www.ccc.com/xss.jsp?id=1&name=2，依次對2個參數進行XSS測試
1.1.1、提交 http://www.ccc.com/xss.jsp?id=1”><script>alert(/xxx/)</script><!--&name=2，根據返回頁面是否彈出包含xxx字符串的窗口判斷是否存在反射型XSS
1.1.2、提交 http://www.ccc.com/xss.jsp?id=1&name=
‘><script>alert(/xxx/)</script><!—
“ onerror=alert(/xxx/) t=”
“ onmousemove=alert(/xxx/) t=”
‘><img src=# onerror=alert(1)>
‘><iframe src=http://www.baidu.com><’
同樣的判斷返回頁面是否彈出包含xxx字符串的窗口判斷是否存在反射型XSS
1.2、存儲型XSS測試：（頁面輸入框進行操作）在頁面表單提交測試中，依次對提交參數進行XSS測試
提交參數語句
‘><script>alert(/xxx/)</script><!—
“ onerror=alert(/xxx/) t=”
“ onmousemove=alert(/xxx/) t=”
‘><img src=# onerror=alert(1)>
</textarea><script>alert(123)</script><!--
‘><iframe src=http://www.baidu.com><’
根據返回頁面是否彈出包含xxx字符串的窗口判斷是否存在存儲型XSS
1.3、 修復建議
對用戶所有輸入的數據進行過濾，在輸入頁面就進行攔截處理，就盡量不要進入到數據庫層面進行交互了。例如："<" ">"、"script"的關鍵字等
對系統輸出的內容進行編碼處理。例如：HTML Entity。
2、任意文件上傳
任意文件上傳漏洞主要是由於程序員在開發文件上傳功能時，沒有考慮對文件格式后綴的合法性進行校驗，或只考慮在應用前端（Web瀏覽器端）通過javascript進行后綴校驗，攻擊者可上傳一個包含惡意代碼的動態腳本（如jsp、asp、php、aspx文件后綴）到服務器上，攻擊者訪問該腳本時服務器將對包含惡意代碼的動態腳本解析，最終執行相應的惡意代碼。該漏洞最終將可能直接影響應用系統的服務器安全，攻擊者可通過所上傳的腳本完全控制服務器。
手工測試：對文件上傳頁面進行測試
2.1、直接上傳（上傳格式進行客戶端校驗）：在上傳過程中，直接選擇動態腳本后綴的文件，如asp、php、jsp、aspx等文件格式，觀察是否上傳成功
2.2、繞過JS上傳（上傳格式進行服務器端校驗）：可以用charles或burpsuite工具進行測試，詳細使用方法可百度或看我抓包工具的博客
當上傳頁面在前端采用javascript進行文件后綴限制時，可通過HTTP抓包工具進行改包上傳，將文件后綴修改為動態腳本后綴並上傳提交，如果響應中顯示上傳成功，並且數據庫里也多了一條材料數據，則需要修改
2.3、截斷后綴上傳：上傳處理將識別到%00，並對后綴.png截斷刪除，如果最終顯示微信.aspx文件上傳成功，並且數據庫里新增了數據，則需要修改
部分上傳功能在對后綴名進行驗證時存在缺陷，導致在文件寫入過程中產生錯誤，導致可通過十六進制截斷符（%00）對后綴進行截斷
比如上傳一個文件360.asp%00.jpg，上傳處理時檢測到%00並對.jpg字符串進行截斷刪除，最終導致360.asp動態腳本成功上傳到了服務器
2.4、不允許繞過Content-Type檢查上傳：只識別了文件類型，並沒有看文件格式，導致可通過改包的方式上傳動態腳本到服務器上
比如Content-Type的參數值為image/jpg，程序會認為本次提交的為圖片格式類型，並沒有對文件格式進行后綴驗證，最終成功繞過Content-Type檢查，將aspx動態腳本到服務器上
2.5、 修復建議
禁止上傳任意文件。對上傳的文件后綴進行限制
3、 任意文件下載或讀取
由於應用系統在提供文件下載或讀取功能時，在文件路徑參數中直接指定文件路徑的同時，並沒有對文件路徑的合法性進行校驗，導致攻擊者可以通過目錄跳轉（..\或../）的方式下載或讀取到原始知道路徑之外的文件，攻擊者可以通過該漏洞下載或讀取系統上的任意文件，比如數據庫文件，應用系統源代碼，密碼配置等敏感信息，造成系統的敏感信息泄露。
手工測試：
對存在文件下載或文件讀取功能的頁面進行測試，查看所提交的參數中是否包含文件名或文件目錄，嘗試提交參數值查看是否可下載或讀取其他目錄的文件內容；
比如：原始下載功能路徑為http://www.ccc.com/donwload.jsp?filename=test123456789.pdf
其中文件路徑參數為filename，通過../對路徑進行跳轉嘗試下載其他目錄下的文件，修改filename參數為../../WEB-INF/web.xml嘗試下載JSP網站的配置文件（測試過程中需適當增加../跳轉字符串）；如提交
http://www.ccc.com/donwload.jsp?filename=../../WEB-INF/web.xml
查看是否成功下載web.xml文件。
另一種情況如下：
http://www.ccc.com/donwload.jsp?filepath=uploadfile&filename=test123.pdf
該功能通過filepath以及filename指定下載目錄以及下載文件名，可修改filepath參數值進行路徑跳轉，同時修改filename值指定文件名；如提交
http://www.ccc.com/donwload.jsp?filepath=../../WEB-INF&filename=web.xml
查看是否成功下載web.xml文件。
4、信息泄露
信息泄露主要是由於開發人員或運維管理人員的疏忽所導致。如未及時刪除調試頁面、未關閉程序調試功能、未屏蔽程序錯誤信息、備份文件未刪除、數據庫備份文件未刪除、未屏蔽敏感數據信息等多個方面所導致的不同嚴重程度的信息泄露。攻擊者可通過所掌握的信息進一步分析攻擊目標，從而有效發起下一步的有效攻擊。
手工/工具測試：
通過目錄掃描工具掃描查看是否存在敏感路徑；
通過文件掃描工具掃描查看是否存在敏感文件；
通過HTTP抓包工具觀察請求響應中是否包含敏感的信息返回；
通過手工提交畸形的參數名或參數值嘗試引起程序跑出異常，如提交單引號，超長字符串，異常編碼字符串等方式；
修復建議
禁止使用服務器的絕對路徑進行文件類的操作。
二、業務邏輯安全漏洞
5、未授權訪問（直接在未登錄情況下操作登錄成功之后的頁面）
應用系統對業務功能頁面並未進行有效的身份校驗，在未登錄且獲知業務功能頁面的訪問地址前提下，可直接操作該頁面下的功能，將可能對應用系統的惡意破壞
手工測試：
成功登錄后記錄各個功能頁面的URL，重啟瀏覽器並直接訪問所記錄的各個URL，查看是否可訪問成功；
最后在項目實例中發現：后台URL添加單引號直接顯示了后台的部分功能，應修改
6、登錄時驗證碼缺陷
常見於應用系統在登錄處理流程過程中，當用戶登錄失敗后並未對當前驗證碼進行注銷並重新刷新驗證碼，攻擊者可至始至終提交初始的驗證碼發起攻擊窮舉攻擊；同時部分應用系統驗證碼只在客戶端瀏覽器驗證，並未經過服務器遠程驗證，將可能存在繞過驗證碼缺陷，另一方面，在生成或獲取驗證碼的過程中存在缺陷，攻擊者將可能成功預測驗證碼內容或直接解析驗證碼內容，從而使驗證碼失去原有意義，最終導致一系列的窮舉或遍歷數據攻擊。
手工測試:
賬號密碼如果后台設置了密文，抓包工具獲取到的是否密文展示
對存在驗證碼的功能頁面進行刷新，觀察驗證碼生成是否具有足夠的隨機性；
對存在驗證碼的功能頁面進行刷新並通過HTTP抓包工具抓取當前請求包，查看驗證碼的獲取過程，分析獲取過程中是否存在缺陷可導致驗證碼被解析破解；
對存在驗證碼的功能頁面進行數據提交，並通過HTTP抓包工具抓取當前請求包，最后重新對該請求數據包進行重放，查看是否請求失敗或提示驗證碼錯誤，如請求成功，即驗證碼並未進行有效的刷新；
7、任意手機號注冊：
常見於應用系統在登錄處理流程過程中，當用戶登錄失敗后並未對當前驗證碼進行注銷並重新刷新驗證碼，攻擊者可至始至終提交初始的驗證碼發起攻擊窮舉攻擊；同時部分應用系統驗證碼只在客戶端瀏覽器驗證，並未經過服務器遠程驗證，將可能存在繞過驗證碼缺陷，另一方面，在生成或獲取驗證碼的過程中存在缺陷，攻擊者將可能成功預測驗證碼內容或直接解析驗證碼內容，從而使驗證碼失去原有意義，最終導致一系列的窮舉或遍歷數據攻擊。
8、密碼爆破