（ 圖片來源： 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"

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

先看個(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ù)庫。試想一下，如果用戶傳入的 password 值是： "password’ OR 1=1"，那么 sql 語句便會(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īng)用使用 SQL 來控制數(shù)據(jù)庫

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

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

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

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

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

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

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)景下要求的粒度不一樣。

簡(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"

參考：

Cross-site scripting -- MDN

XSS Tutorial

微信公眾號(hào)【給產(chǎn)品經(jīng)理講技術(shù)】 -- Web安全之CSRF攻擊

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

SQL Injection (SQLi)

SQL Injection

SQL Injection Prevention Cheat Sheet

DDoS，并沒有想象中那么可怕

互聯(lián)網(wǎng)黑市分析：DDoS 啟示錄

DDoS，網(wǎng)絡(luò)安全世界里的暗黑殺手