好哦，所以在產出弱點掃描結果之後呢～
最麻煩的就是驗證這些弱點是否「真正的存在」，需要自動排除「工具誤判」的弱點，
驗證是弱點掃描之後最需要時間的部份了… ((眼神死

我們通常會使用幾項工具，像說BurpSuite、SQLmap、Hackerbar…或其他工具，
去驗證這些工具產出的報告，是否有真正的弱點。

以下列出幾個常見的弱點：
(1) Blind SQL Injection
Web 應用程式未檢查使用者的輸入參數，直接將其傳入資料庫執行SQL，可能造成繞過身份驗證、任意查詢/新增/修改/刪除資料庫內容、資料庫伺服器遭入侵等危害。
驗證方式：sqlmap

(2) Cross site scripting
受測網址允許瀏覽者輸入HTML格式資料，且回應頁面中會包含瀏覽者所輸入資料。攻擊者可藉此方式植入網頁腳本程式語法，導致其他用戶連線時被竊取機密資訊，或讓攻擊者藉由此網址假造惡意連結欺騙瀏覽者。
驗證方式：URL+欄位+參數

(3) Development configuration file
設定檔外洩可能會暴露敏感資訊，或被進階攻擊使用。
驗證方式：URL

(4) Application error message
頁面連線時，由於傳遞的參數或變數造成頁面出現異常或錯誤訊息。
驗證方式：URL+HackerBar

(5) HTML form without CSRF protection
Cross-Site Request Forgery (CSRF) 主要的攻擊行為就是利用當使用者合法取得網站使用認證後，透過某些方式偽造網站合法使用者的身份進行非法的存取動作，合法使用者即可能在不自覺的情況下被引導到攻擊者的惡意網頁。
驗證方式：URL+參數+Burpsuite

(6) RC4 cipher suites detected
RC4加密是一種有缺陷加密方式，攻擊者可以實施暴力破解取得明文。
驗證方式：Kali(tlssled)
語法說明：tlssled {HOSTNAME | IP} PORT
執行範例：tlssled www.google.com 443

(7) Clickjacking: X-Frame-Options header missing
HTTP Header未使用X-Frame-Options的header，若有Clickjacking的弱點，則無相對應檢查的機制。
驗證方式：URL+瀏覽器右鍵Inspect Element

(8) Cookie(s) without HttpOnly flag set
攻擊者可利用此弱點搭配Cross-Site Scripting(XSS) 以取得session cookie，進而冒用他人身分或竊取Cookie中的機敏資料。
驗證方式：URL+瀏覽器右鍵Inspect Element

(9) Login page password-guessing attack
限制無效登入的次數，可能允許攻擊者進行暴力破解攻擊
驗證方式：使用弱點掃瞄工具驗證

(10)Possible sensitive directories
發現多個可能的敏感目錄，疑似備份目錄、資料庫目庫、元件庫、管理頁面或臨時目錄，容易曝露網頁結構，這些目錄中的可以幫助攻擊者更多地了解他的目標。
驗證方式：URL驗證

= = = = = = = = = =修復參考= = = = = = = = = =
網站資源
https://www.acunetix.com/vulnerabilities/web/