Web漏洞

1.SQL注入：

緣由：

　SQL 注入就是經過給 web 應用接口傳入一些特殊字符，達到欺騙服務器執行惡意的 SQL 命令，當使用外部不可信任的數據做爲參數進行數據庫的增、刪、改、查時，若是未對外部數據進行過濾，就會產生 SQL 注入漏洞。

解決方案：

具體的解決方案不少，但大部分都是基於一點：不信任任何外部輸入。

因此，對任何外部輸入都進行過濾，而後再進行數據庫的增、刪、改、查。

此外，適當的權限控制、不曝露必要的安全信息和日誌也有助於預防 SQL 注入漏洞

2.XSS 攻擊:

緣由：

　　XSS 攻擊全稱跨站腳本攻擊（Cross-Site Scripting），簡單的說就是攻擊者經過在目標網站上注入惡意腳本並運行，獲取用戶的敏感信息如 Cookie、SessionID 等，影響網站與用戶數據安全。

當攻擊者經過某種方式向瀏覽器頁面注入了惡意代碼，而且瀏覽器執行了這些代碼。

好比：在一個文章應用中（如微信文章），攻擊者在文章編輯後臺經過注入 script 標籤及 js 代碼，後端未加過濾就保存到數據庫，前端渲染文章詳情的時候也未加過濾，這就會讓這段 js 代碼執行，引發 XSS 攻擊。

解決方案：

一個基本的思路是渲染前端頁面（不論是客戶端渲染仍是服務器端渲染）或者動態插入 HTML 片斷時，任何數據都不可信任，都要先作 HTML 過濾，而後再渲染。

3.CSRF 攻擊

緣由：

CSRF 攻擊全稱跨站請求僞造（Cross-site Request Forgery），簡單的說就是攻擊者盜用了你的身份，以你的名義發送惡意請求。

一個典型的 CSRF 攻擊有着以下的流程：

• 受害者登陸 a.com，並保留了登陸憑證（Cookie）
• 攻擊者引誘受害者訪問了 b.com
• b.com 向 a.com 發送了一個請求：a.com/act=xx（瀏覽器會默認攜帶 a.com 的 Cookie）
• a.com 接收到請求後，對請求進行驗證，並確認是受害者的憑證，誤覺得是受害者本身發送的請求
• a.com 以受害者的名義執行了 act=xx
• 攻擊完成，攻擊者在受害者不知情的狀況下，冒充受害者，讓 a.com 執行了本身定義的操做

解決方案：

• 阻止不明外域的訪問

  • 同源檢測
  • Samesite Cookie

• 提交時要求附加本域才能獲取的信息

• CSRF Token
• 雙重Cookie驗證

雙重Cookie採用如下流程：

• 在用戶訪問網站頁面時，向請求域名注入一個Cookie，內容爲隨機字符串（例如csrfcookie=v8g9e4ksfhw）。
• 在前端向後端發起請求時，取出Cookie，並添加到URL的參數中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。
• 後端接口驗證Cookie中的字段與URL參數中的字段是否一致，不一致則拒絕

CSRF Token的防禦策略分爲三個步驟：

1.將CSRF Token輸出到頁面中

2.頁面提交的請求攜帶這個Token

3.服務器驗證Token是否正確

 4.DDoS攻擊

緣由：

分佈式拒絕服務（DDoS）攻擊是一種惡意企圖，經過大量互聯網流量壓倒目標或其周圍的基礎架構來破壞目標服務器，服務或網絡的正常流量。DDoS攻擊經過利用多個受損計算機系統做爲攻擊流量來源來實現有效性。

攻擊者不斷地提出服務請求，讓合法用戶的請求沒法及時處理，這就是 DoS 攻擊。

攻擊者使用多臺計算機或者計算機集羣進行 DoS 攻擊，就是 DDoS 攻擊。

解決方案：

防止 DDoS 攻擊的基本思路是限流，限制單個用戶的流量（包括 IP 等）。

5. XXE 漏洞

緣由：

XXE 漏洞全稱 XML 外部實體漏洞（XML External Entity），當應用程序解析 XML 輸入時，若是沒有禁止外部實體的加載，致使可加載惡意外部文件和代碼，就會形成任意文件讀取、命令執行、內網端口掃描、攻擊內網網站等攻擊。

這個只在可以接收 XML 格式參數的接口才會出現。

解決方案：

• 禁用外部實體
• 過濾用戶提交的XML數據

 

6.暴力破解

緣由：

這個通常針對密碼而言，弱密碼（Weak Password）很容易被別人（對你很瞭解的人等）猜到或被破解工具暴力破解。

解決方案：

• 密碼複雜度要足夠大，也要足夠隱蔽
• 限制嘗試次數

7.HTTP 報頭追蹤漏洞

緣由：

HTTP/1.1（RFC2616）規範定義了 HTTP TRACE 方法，主要是用於客戶端經過向 Web 服務器提交 TRACE 請求來進行測試或得到診斷信息。

當 Web 服務器啓用 TRACE 時，提交的請求頭會在服務器響應的內容（Body）中完整的返回，其中 HTTP 頭極可能包括 Session Token、Cookies 或其它認證信息。攻擊者能夠利用此漏洞來欺騙合法用戶並獲得他們的私人信息。

解決方案：

禁用 HTTP TRACE 方法。

8.信息泄露

緣由：

信息泄露漏洞是因爲Web服務器或應用程序沒有正確處理一些特殊請求，泄露Web服務器的一些敏感信息，如用戶名、密碼、源代碼、服務器信息、配置信息等

–Web服務器配置存在問題，致使一些系統文件或者配置文件暴露在互聯網中；

–Web服務器自己存在漏洞，在瀏覽器中輸入一些特殊的字符，能夠訪問未受權的文件或者動態腳本文件源碼；

–Web網站的程序編寫存在問題，對用戶提交請求沒有進行適當的過濾，直接使用用戶提交上來的數據。

解決方案：

• 應用程序報錯時，不對外產生調試信息
• 過濾用戶提交的數據與特殊字符
• 保證源代碼、服務器配置的安全

9.目錄遍歷漏洞

緣由：

攻擊者向 Web 服務器發送請求，經過在 URL 中或在有特殊意義的目錄中附加 ../、或者附加 ../ 的一些變形（如 ..\ 或 ..// 甚至其編碼），致使攻擊者可以訪問未受權的目錄，以及在 Web 服務器的根目錄之外執行命令。

10.命令執行漏洞

緣由：

命令執行漏洞是經過URL發起請求，在Web服務器端執行未受權的命令，獲取系統信息，篡改系統配置，控制整個系統，使系統癱瘓等。

命令執行漏洞主要有兩種狀況：

–經過目錄遍歷漏洞，訪問系統文件夾，執行指定的系統命令；

–攻擊者提交特殊的字符或者命令，Web程序沒有進行檢測或者繞過Web應用程序過濾，把用戶提交的請求做爲指令進行解析，致使執行任意命令。

11.文件上傳漏洞

緣由：

文件包含漏洞是由攻擊者向Web服務器發送請求時，在URL添加非法參數，Web服務器端程序變量過濾不嚴，把非法的文件名做爲參數處理。這些非法的文件名能夠是服務器本地的某個文件，也能夠是遠端的某個惡意文件。

解決方案：

• 在開發網站及應用程序過程當中，需嚴格限制和校驗上傳的文件，禁止上傳惡意代碼的文件
• 限制相關目錄的執行權限，防範 webshell 攻擊