web 應用常見安全漏洞一覽
1. SQL 注入
SQL 注入就是通過給 web 應用介面傳入一些特殊字元，達到欺騙伺服器執行惡意的 SQL 命令。
SQL 注入漏洞屬於後端的範疇，但前端也可做體驗上的優化。
原因
當使用外部不可信任的資料作為引數進行資料庫的增、刪、改、查時，如果未對外部資料進行過濾，就會產生 SQL 注入漏洞。
比如：
name = "外部輸入名稱";
sql = "select * from users where name=" + name;上面的 SQL 語句目的是通過使用者輸入的使用者名稱查詢使用者資訊，因為由於 SQL 語句是直接拼接的，也沒有進行過濾，所以，當使用者輸入 `` or `1`=`1` 時，這個語句的功能就是搜尋 users 全表的記錄。
select * from users where name=`` or `1`=`1`;解決方案
具體的解決方案很多，但大部分都是基於一點：不信任任何外部輸入。
所以，對任何外部輸入都進行過濾，然後再進行資料庫的增、刪、改、查。
此外，適當的許可權控制、不曝露必要的安全資訊和日誌也有助於預防 SQL 注入漏洞。
參考 Web 安全漏洞之 SQL 注入 – 防禦方法 瞭解具體的解決方案。
推薦參考
2. XSS 攻擊
XSS 攻擊全稱跨站指令碼攻擊（Cross-Site Scripting），簡單的說就是攻擊者通過在目標網站上注入惡意指令碼並執行，獲取使用者的敏感資訊如 Cookie、SessionID 等，影響網站與使用者資料安全。
XSS 攻擊更偏向前端的範疇，但後端在儲存資料的時候也需要對資料進行安全過濾。
原因
當攻擊者通過某種方式向瀏覽器頁面注入了惡意程式碼，並且瀏覽器執行了這些程式碼。
比如：
在一個文章應用中（如微信文章），攻擊者在文章編輯後臺通過注入 script 標籤及 js 程式碼，後端未加過濾就儲存到資料庫，前端渲染文章詳情的時候也未加過濾，這就會讓這段 js 程式碼執行，引起 XSS 攻擊。
解決方案
一個基本的思路是渲染前端頁面（不管是客戶端渲染還是伺服器端渲染）或者動態插入 HTML 片段時，任何資料都不可信任，都要先做 HTML 過濾，然後再渲染。
參考 前端安全系列（一）：如何防止XSS攻擊？ – 攻擊的預防 瞭解具體的解決方案。
推薦參考
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執行了自己定義的操作
注：上面的過程摘自 前端安全系列之二：如何防止CSRF攻擊？
解決方案
防止 CSRF 攻擊需要在伺服器端入手，基本的思路是能正確識別是否是使用者發起的請求。
參考 前端安全系列之二：如何防止CSRF攻擊？ – 防護策略 瞭解具體的解決方案。
推薦參考
4. DDoS 攻擊
DoS 攻擊全稱拒絕服務（Denial of Service），簡單的說就是讓一個公開網站無法訪問，而 DDoS 攻擊（分散式拒絕服務 Distributed Denial of Service）是 DoS 的升級版。
這個就完全屬於後端的範疇了。
原因
攻擊者不斷地提出服務請求，讓合法使用者的請求無法及時處理，這就是 DoS 攻擊。
攻擊者使用多臺計算機或者計算機叢集進行 DoS 攻擊，就是 DDoS 攻擊。
解決方案
防止 DDoS 攻擊的基本思路是限流，限制單個使用者的流量（包括 IP 等）。
參考 DDoS的攻擊及防禦 – 防禦 瞭解具體的解決方案。
推薦參考
5. XXE 漏洞
XXE 漏洞全稱 XML 外部實體漏洞（XML External Entity），當應用程式解析 XML 輸入時，如果沒有禁止外部實體的載入，導致可載入惡意外部檔案和程式碼，就會造成任意檔案讀取、命令執行、內網埠掃描、攻擊內網網站等攻擊。
這個只在能夠接收 XML 格式引數的介面才會出現。
解決方案
- 禁用外部實體
- 過濾使用者提交的XML資料
參考 xxe漏洞的學習與利用總結 瞭解具體的解決方案。
推薦參考
6. JSON 劫持
JSON 劫持（JSON Hijacking）是用於獲取敏感資料的一種攻擊方式，屬於 CSRF 攻擊的範疇。
原因
一些 Web 應用會把一些敏感資料以 json 的形式返回到前端，如果僅僅通過 Cookie 來判斷請求是否合法，那麼就可以利用類似 CSRF 的手段，向目標伺服器傳送請求，以獲得敏感資料。
比如下面的連結在已登入的情況下會返回 json 格式的使用者資訊：
http://www.test.com/userinfo攻擊者可以在自己的虛假頁面中，加入如下標籤：
<script src="http://www.test.com/userinfo"></script>如果當前瀏覽器已經登入了 www.test.com，並且 Cookie 未過期，然後訪問了攻擊者的虛假頁面，那麼該頁面就可以拿到 json 形式的使用者敏感資訊，因為 script 標籤會自動解析 json 資料，生成對應的 js 物件。然後再通過：
Object.prototype.__defineSetter__這個函式來觸發自己的惡意程式碼。
但是這個函式在當前的新版本 Chrome 和 Firefox 中都已經失效了。
注：上面的過程摘自 JSON和JSONP劫持以及解決方法
解決方案
-
X-Requested-With標識 - 瀏覽器 JSON 資料識別
- 禁止 Javascript 執行 JSON 資料
推薦參考
7. 暴力破解
這個一般針對密碼而言，弱密碼（Weak Password）很容易被別人（對你很瞭解的人等）猜到或被破解工具暴力破解。
解決方案
- 密碼複雜度要足夠大，也要足夠隱蔽
- 限制嘗試次數
8. HTTP 報頭追蹤漏洞
HTTP/1.1（RFC2616）規範定義了 HTTP TRACE 方法，主要是用於客戶端通過向 Web 伺服器提交 TRACE 請求來進行測試或獲得診斷資訊。
當 Web 伺服器啟用 TRACE 時，提交的請求頭會在伺服器響應的內容（Body）中完整的返回，其中 HTTP 頭很可能包括 Session Token、Cookies 或其它認證資訊。攻擊者可以利用此漏洞來欺騙合法使用者並得到他們的私人資訊。
解決方案
禁用 HTTP TRACE 方法。
9. 資訊洩露
由於 Web 伺服器或應用程式沒有正確處理一些特殊請求，洩露 Web 伺服器的一些敏感資訊，如使用者名稱、密碼、原始碼、伺服器資訊、配置資訊等。
所以一般需注意：
- 應用程式報錯時，不對外產生除錯資訊
- 過濾使用者提交的資料與特殊字元
- 保證原始碼、伺服器配置的安全
10. 目錄遍歷漏洞
攻擊者向 Web 伺服器傳送請求，通過在 URL 中或在有特殊意義的目錄中附加 ../、或者附加 ../ 的一些變形（如 .. 或 ..// 甚至其編碼），導致攻擊者能夠訪問未授權的目錄，以及在 Web 伺服器的根目錄以外執行命令。
11. 命令執行漏洞
命令執行漏洞是通過 URL 發起請求，在 Web 伺服器端執行未授權的命令，獲取系統資訊、篡改系統配置、控制整個系統、使系統癱瘓等。
12. 檔案上傳漏洞
如果對檔案上傳路徑變數過濾不嚴，並且對使用者上傳的檔案字尾以及檔案型別限制不嚴，攻擊者可通過 Web 訪問的目錄上傳任意檔案，包括網站後門檔案（webshell），進而遠端控制網站伺服器。
所以一般需注意：
- 在開發網站及應用程式過程中，需嚴格限制和校驗上傳的檔案，禁止上傳惡意程式碼的檔案
- 限制相關目錄的執行許可權，防範
webshell攻擊
13. 其他漏洞
- SSLStrip 攻擊
- OpenSSL Heartbleed 安全漏洞
- CCS 注入漏洞
- 證照有效性驗證漏洞
14. 業務漏洞
一般業務漏洞是跟具體的應用程式相關，比如引數篡改（連續編號 ID / 訂單、1 元支付）、重放攻擊（偽裝支付）、許可權控制（越權操作）等。
另外可以參考：6種常見web漏洞坑
15. 框架或應用漏洞
- WordPress 4.7 / 4.7.1：REST API 內容注入漏洞
- Drupal Module RESTWS 7.x：Remote PHP Code Execution
- SugarCRM 6.5.23：REST PHP Object Injection Exploit
- Apache Struts：REST Plugin With Dynamic Method Invocation Remote Code Execution
- Oracle GlassFish Server：REST CSRF
- QQ Browser 9.6：API 許可權控制問題導致洩露隱私模式
- Hacking Docker：Registry API 未授權訪問
後續
更多部落格，檢視 https://github.com/senntyou/blogs
版權宣告：自由轉載-非商用-非衍生-保持署名（創意共享3.0許可證）