web 安全入門

搞 Web 開發離不開安全這個話題，確保網站或者網頁應用的安全性，是每一個開發人員都應該瞭解的事。本篇主要簡單介紹在 Web 領域幾種常見的攻擊手段。

1. Cross Site Script（XSS， 跨站腳本攻擊)

首先插播一句，爲毛叫 XSS，縮寫明顯是 CSS 啊？沒錯，爲了防止與咱們熟悉的 CSS（Cascading Style Sheets）混淆，因此乾脆改名爲 XSS。

那 XSS 是什麼呢？一言蔽之，XSS 就是攻擊者在 Web 頁面中插入惡意腳本，當用戶瀏覽頁面時，促使腳本執行，從而達到攻擊目的。XSS 的特色就是想盡一切辦法在目標網站上執行第三方腳本。

( 圖片來源：XSS Tutorial )

舉個例子。原有的網站有個將數據庫中的數據顯示到頁面的上功能，document.write("data from server")。但若是服務器沒有驗證數據類型，直接接受任何數據時，攻擊者能夠會將 <script src='http:bad-script.js'></scirpt> 當作一個數據寫入數據庫。當其餘用戶請求這個數據時，網站原有的腳本就會執行 document.write("<script src='http://www.evil.com/bad-script.js'></scirpt>")，這樣，便會執行 bad-script.js。若是攻擊者在這段第三方的腳本中寫入惡意腳本，那麼普通用戶便會受到攻擊。

XSS 主要有三種類型：

• 存儲型 XSS： 注入的腳本永久的存在於目標服務器上，每當受害者向服務器請求此數據時就會從新喚醒攻擊腳本；

• 反射型 XSS： 當用受害者被引誘點擊一個惡意連接，提交一個僞造的表單，惡意代碼便會和正常返回數據一塊兒做爲響應發送到受害者的瀏覽器，從而騙過了瀏覽器，使之誤覺得惡意腳原本自於可信的服務器，以致於讓惡意腳本得以執行。

（ 圖片來源： Cross-Site Scripting (XSS) ）

• DOM 型 XSS： 有點相似於存儲型 XSS，但存儲型 XSS 是將惡意腳本做爲數據存儲在服務器中，每一個調用數據的用戶都會受到攻擊。但 DOM 型 XSS 則是一個本地的行爲，更可能是本地更新 DOM 時致使了惡意腳本執行。

那麼如何防護 XSS 攻擊呢？

• 從客戶端和服務器端雙重驗證全部的輸入數據，這通常能阻擋大部分注入的腳本

• 對全部的數據進行適當的編碼

• 設置 HTTP Header： "X-XSS-Protection: 1"

2. SQL Injection （SQL 注入）

所謂 SQL 注入，就是經過客戶端的輸入把 SQL 命令注入到一個應用的數據庫中，從而得以執行惡意 SQL 語句。

先看個例子。

uname = request.POST['username']
password = request.POST['password']

sql = "SELECT all FROM users WHERE username='" + uname + "' AND password='" + password + "'"

database.execute(sql)

上面這段程序直接將客戶端傳過來的數據寫入到數據庫。試想一下，若是用戶傳入的 password 值是： "password’ OR 1=1"，那麼 sql 語句便會變成：

sql = "SELECT all FROM users WHERE username='username' AND password='password' OR 1=1"

那麼，這句 sql 不管 username 和 password 是什麼都會執行，從而將全部用戶的信息取出來。

那麼怎麼預防 sql 的問題呢？

想要提出解決方案，先看看 sql 注入得以施行的因素：

• 網頁應用使用 SQL 來控制數據庫

• 用戶傳入的數據直接被寫入數據庫

根據 OWASP，下面看看具體的預防措施。

• Prepared Statements (with Parameterized Queries)： 參數化的查詢語句能夠強制應用開發者首先定義全部的 sql 代碼，以後再將每一個參數傳遞給查詢語句

• Stored Procedures： 使用語言自帶的存儲程序，而不是本身直接操縱數據庫

• White List Input Validation： 驗證用戶的輸入

• Escaping All User Supplied Input： 對用戶提供的全部的輸入都進行編碼

3. Distributed Denial of Service （DDoS， 分佈式拒絕服務）

DoS 攻擊就是經過大量惡意流量佔用帶寬和計算資源以達到癱瘓對方網絡的目的。

舉個簡單的例子，老鄭家麪館生意紅火，忽然有一天一羣小混混進了點，霸佔了座位，只閒聊不點菜，結果坐在店裏的人不吃麪，想吃麪的人進不來，致使老鄭沒法向正常客戶服務。

而 DDoS 攻擊就是將多個計算機聯合起來一同向目標發起攻擊，從而成倍地提升拒絕服務攻擊的威力。

（圖片來源於： DDoSCoin - An Incentive to Launch DDoS Attacks?）

通常 DDoS 攻擊有兩個目的：

• 敲詐勒索，逼你花錢買平安

• 打擊競爭對手

在技術角度上，DDoS攻擊能夠針對網絡通信協議的各層，手段大體有：TCP類的SYN Flood、ACK Flood，UDP類的Fraggle、Trinoo，DNS Query Flood，ICMP Flood，Slowloris類、各類社工方式等等，這些技術這裏不作詳細解釋。可是通常會根據攻擊目標的狀況，針對性的把技術手法混合，以達到最低的成本最難防護的目的，而且能夠進行合理的節奏控制，以及隱藏保護攻擊資源。

阿里巴巴的安全團隊在實戰中發現，DDoS 防護產品的核心是檢測技術和清洗技術。檢測技術就是檢測網站是否正在遭受 DDoS 攻擊，而清洗技術就是清洗掉異常流量。而檢測技術的核心在於對業務深入的理解，才能快速精確判斷出是否真的發生了 DDoS 攻擊。清洗技術對檢測來說，不一樣的業務場景下要求的粒度不同。

4. Cross Site Request Forgery (CSRF， 跨站請求僞造)

簡單來講，CSRF 就是網站 A 對用戶創建信任關係後，在網站 B 上利用這種信任關係，跨站點向網站 A 發起一些僞造的用戶操做請求，以達到攻擊的目的。

舉個例子。網站 A 是一家銀行的網站，一個轉帳接口是 "http://www.bankA.com/transfer?toID=12345678&cash=1000"。toID 表示轉帳的目標帳戶，cash 表示轉帳數目。固然這個接口無法隨便調用，只有在已經驗證的狀況下才可以被調用。

此時，攻擊者創建了一個 B 網站，裏面放了一段隱藏的代碼，用來調用轉帳的接口。當受害者先成功登陸了 A 網站，短期內不須要再次驗證，這個時候又訪問了網站 B，B 裏面隱藏的惡意代碼就可以成功執行。

那怎麼預防 CSRF 攻擊呢？OWASP 推薦了兩種檢查方式來做爲防護手段。

• 檢查標準頭部，確認請求是否同源： 檢查 source origin 和 target origin，而後比較兩個值是否匹配

• 檢查 CSRF Token： 主要有四種推薦的方式

  • Synchronizer Tokens： 在表單裏隱藏一個隨機變化的 token，每當用戶提交表單時，將這個 token 提交到後臺進行驗證，若是驗證經過則能夠繼續執行操做。這種狀況有效的主要緣由是網站 B 拿不到網站 A 表單裏的 token;

  • Double Cookie Defense： 當向服務器發出請求時，生成一個隨機值，將這個隨機值既放在 cookie 中，也放在請求的參數中，服務器同時驗證這兩個值是否匹配；

  • Encrypted Token Pattern： 對 token 進行加密

  • Custom Header： 使用自定義請求頭部，這個方式依賴於同源策略。其中最適合的自定義頭部即是： "X-Requested-With: XMLHttpRequest"

參考：

1. Cross-site scripting -- MDN

2. XSS Tutorial

3. 微信公衆號【給產品經理講技術】 -- Web安全之CSRF攻擊

4. Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet_Prevention_Cheat_Sheet)

5. SQL Injection (SQLi)

6. SQL Injection

7. SQL Injection Prevention Cheat Sheet

8. DDoS，並無想象中那麼可怕

9. 互聯網黑市分析：DDoS 啓示錄

10. DDoS，網絡安全世界裏的暗黑殺手