非持久型 XSS 漏洞，也叫反射型 XSS 漏洞，一般是通過(guò)給別人發(fā)送帶有惡意腳本代碼參數(shù)的 URL，當(dāng) URL 地址被打開(kāi)時(shí)，特有的惡意代碼參數(shù)被 HTML 解析、執(zhí)行。

舉一個(gè)例子，比如你的 Web 頁(yè)面中包含有以下代碼：

為了防止持久型 XSS 漏洞，需要前后端共同努力：

其實(shí)現(xiàn)在很多的瀏覽器以及各種開(kāi)源的庫(kù)都專(zhuān)門(mén)針對(duì)了 XSS 進(jìn)行轉(zhuǎn)義處理，盡量默認(rèn)抵御絕大多數(shù) XSS 攻擊，但是還是有很多方式可以繞過(guò)轉(zhuǎn)義規(guī)則，讓人防不勝防。比如「基于字符集的 XSS 攻擊」就是繞過(guò)這些轉(zhuǎn)義處理的一種攻擊方式，比如有些 Web 頁(yè)面字符集不固定，用戶(hù)輸入非期望字符集的字符，有時(shí)會(huì)繞過(guò)轉(zhuǎn)義過(guò)濾規(guī)則。

以基于 utf-7 的 XSS 為例utf-7 是可以將所有的 unicode 通過(guò) 7bit 來(lái)表示的一種字符集 (但現(xiàn)在已經(jīng)從 Unicode 規(guī)格中移除)。這個(gè)字符集為了通過(guò) 7bit 來(lái)表示所有的文字, 除去數(shù)字和一部分的符號(hào),其它的部分將都以 base64 編碼為基礎(chǔ)的方式呈現(xiàn)。

可以形成「基于字符集的 XSS 攻擊」的原因是由于瀏覽器在 meta 沒(méi)有指定 charset 的時(shí)候有自動(dòng)識(shí)別編碼的機(jī)制，所以這類(lèi)攻擊通常就是發(fā)生在沒(méi)有指定或者沒(méi)來(lái)得及指定 meta 標(biāo)簽的 charset 的情況下。

所以我們有什么辦法避免這種 XSS 呢？

基于 Flash 的跨站 XSS 也是屬于反射型 XSS 的一種，雖然現(xiàn)在開(kāi)發(fā) ActionScript 的產(chǎn)品線幾乎沒(méi)有了，但還是提一句吧，AS 腳本可以接受用戶(hù)輸入并操作 cookie，攻擊者可以配合其他 XSS（持久型或者非持久型）方法將惡意 swf 文件嵌入頁(yè)面中。主要是因?yàn)?AS 有時(shí)候需要和 JS 傳參交互，攻擊者會(huì)通過(guò)惡意的 XSS 注入篡改參數(shù)，竊取并操作cookie。

避免方法：

有一些場(chǎng)景是后端需要對(duì)一個(gè)傳進(jìn)來(lái)的待跳轉(zhuǎn)的 URL 參數(shù)進(jìn)行一個(gè) 302 跳轉(zhuǎn)，可能其中會(huì)帶有一些用戶(hù)的敏感（cookie）信息。如果服務(wù)器端做302 跳轉(zhuǎn)，跳轉(zhuǎn)的地址來(lái)自用戶(hù)的輸入，攻擊者可以輸入一個(gè)惡意的跳轉(zhuǎn)地址來(lái)執(zhí)行腳本。

這時(shí)候需要通過(guò)以下方式來(lái)防止這類(lèi)漏洞：

完成 CSRF 攻擊必須要有三個(gè)條件：

你也許會(huì)問(wèn)：「如果我不滿足以上三個(gè)條件中的任意一個(gè)，就不會(huì)受到 CSRF 的攻擊」。其實(shí)可以這么說(shuō)的，但你不能保證以下情況不會(huì)發(fā)生：

當(dāng)正確的使用了 GET 和 POST 請(qǐng)求之后，剩下的就是在非 GET 方式的請(qǐng)求中增加隨機(jī)數(shù)，這個(gè)大概有三種方式來(lái)進(jìn)行：

CSRF 的防御可以根據(jù)應(yīng)用場(chǎng)景的不同自行選擇。CSRF 的防御工作確實(shí)會(huì)在正常業(yè)務(wù)邏輯的基礎(chǔ)上帶來(lái)很多額外的開(kāi)發(fā)量，但是這種工作量是值得的，畢竟用戶(hù)隱私以及財(cái)產(chǎn)安全是產(chǎn)品最基礎(chǔ)的根本。

SQL 注入漏洞（SQL Injection）是 Web 開(kāi)發(fā)中最常見(jiàn)的一種安全漏洞。可以用它來(lái)從數(shù)據(jù)庫(kù)獲取敏感信息，或者利用數(shù)據(jù)庫(kù)的特性執(zhí)行添加用戶(hù)，導(dǎo)出文件等一系列惡意操作，甚至有可能獲取數(shù)據(jù)庫(kù)乃至系統(tǒng)用戶(hù)最高權(quán)限。

而造成 SQL 注入的原因是因?yàn)槌绦驔](méi)有有效的轉(zhuǎn)義過(guò)濾用戶(hù)的輸入，使攻擊者成功的向服務(wù)器提交惡意的 SQL 查詢(xún)代碼，程序在接收后錯(cuò)誤的將攻擊者的輸入作為查詢(xún)語(yǔ)句的一部分執(zhí)行，導(dǎo)致原始的查詢(xún)邏輯被改變，額外的執(zhí)行了攻擊者精心構(gòu)造的惡意代碼。

很多 Web 開(kāi)發(fā)者沒(méi)有意識(shí)到 SQL 查詢(xún)是可以被篡改的，從而把 SQL 查詢(xún)當(dāng)作可信任的命令。殊不知，SQL 查詢(xún)是可以繞開(kāi)訪問(wèn)控制，從而繞過(guò)身份驗(yàn)證和權(quán)限檢查的。更有甚者，有可能通過(guò) SQL 查詢(xún)?nèi)ミ\(yùn)行主機(jī)系統(tǒng)級(jí)的命令。

下面將通過(guò)一些真實(shí)的例子來(lái)詳細(xì)講解 SQL 注入的方式的原理。

考慮以下簡(jiǎn)單的管理員登錄表單：

后端的 SQL 語(yǔ)句可能是如下這樣的：

目的就是來(lái)驗(yàn)證用戶(hù)名和密碼是不是正確，按理說(shuō)乍一看上面的 SQL 語(yǔ)句也沒(méi)什么毛病，確實(shí)是能夠達(dá)到我們的目的，可是你只是站在用戶(hù)會(huì)老老實(shí)實(shí)按照你的設(shè)計(jì)來(lái)輸入的角度來(lái)看問(wèn)題，如果有一個(gè)惡意攻擊者輸入的用戶(hù)名是 zoumiaojiang' OR 1 = 1 --，密碼隨意輸入，就可以直接登入系統(tǒng)了。WFT!

冷靜下來(lái)思考一下，我們之前預(yù)想的真實(shí) SQL 語(yǔ)句是:

可以惡意攻擊者的奇怪用戶(hù)名將你的 SQL 語(yǔ)句變成了如下形式：

在 SQL 中，-- 是注釋后面的內(nèi)容的意思，所以查詢(xún)語(yǔ)句就變成了：

這條 SQL 語(yǔ)句的查詢(xún)條件永遠(yuǎn)為真，所以意思就是惡意攻擊者不用我的密碼，就可以登錄進(jìn)我的賬號(hào)，然后可以在里面為所欲為，然而這還只是最簡(jiǎn)單的注入，牛逼 的 SQL 注入高手甚至可以通過(guò) SQL 查詢(xún)?nèi)ミ\(yùn)行主機(jī)系統(tǒng)級(jí)的命令，將你主機(jī)里的內(nèi)容一覽無(wú)余，這里我也沒(méi)有這個(gè)能力講解的太深入，畢竟不是專(zhuān)業(yè)研究這類(lèi)攻擊的，但是通過(guò)以上的例子，已經(jīng)了解了 SQL 注入的原理，我們基本已經(jīng)能找到防御 SQL 注入的方案了。

碰到要操作的數(shù)據(jù)庫(kù)的代碼，一定要慎重，小心使得萬(wàn)年船，多找?guī)讉€(gè)人多來(lái)幾次 code review，將問(wèn)題都暴露出來(lái)，而且要善于利用工具，操作數(shù)據(jù)庫(kù)相關(guān)的代碼屬于機(jī)密，沒(méi)事不要去各種論 壇曬自家站點(diǎn)的 SQL 語(yǔ)句，萬(wàn)一被人盯上了呢？

命令行注入漏洞，指的是攻擊者能夠通過(guò) HTTP 請(qǐng)求直接侵入主機(jī)，執(zhí)行攻擊者預(yù)設(shè)的 shell 命令，聽(tīng)起來(lái)好像匪夷所思，這往往是 Web 開(kāi)發(fā)者最容易忽視但是卻是最危險(xiǎn)的一個(gè)漏洞之一，看一個(gè)實(shí)例：

假如現(xiàn)在需要實(shí)現(xiàn)一個(gè)需求：用戶(hù)提交一些內(nèi)容到服務(wù)器，然后在服務(wù)器執(zhí)行一些系統(tǒng)命令去產(chǎn)出一個(gè)結(jié)果返回給用戶(hù)，接口的部分實(shí)現(xiàn)如下：

還是前面的例子，我們可以做到如下：

ICMP Flood 攻擊

ICMP Flood 攻擊屬于大流量攻擊，其原理就是不斷發(fā)送不正常的 ICMP 包（所謂不正常就是 ICMP 包內(nèi)容很大），導(dǎo)致目標(biāo)帶寬被占用，但其本身資源也會(huì)被消耗。目前很多服務(wù)器都是禁 ping 的（在防火墻在可以屏蔽 ICMP 包），因此這種攻擊方式已經(jīng)落伍。

利用 XSS

舉個(gè)例子，如果 12306 頁(yè)面有一個(gè) XSS 持久型漏洞被惡意攻擊者發(fā)現(xiàn)，只需在春節(jié)搶票期間在這個(gè)漏洞中執(zhí)行腳本使得往某一個(gè)小站點(diǎn)隨便發(fā)點(diǎn)什么請(qǐng)求，然后隨著用戶(hù)訪問(wèn)的增多，感染用戶(hù)增多，被攻擊的站點(diǎn)自然就會(huì)迅速癱瘓了。這種 DDoS 簡(jiǎn)直就是無(wú)本萬(wàn)利，不用驚訝，現(xiàn)在大站有 XSS 漏洞的不要太多。

來(lái)自 P2P 網(wǎng)絡(luò)攻擊

大家都知道，互聯(lián)網(wǎng)上的 P2P 用戶(hù)和流量都是一個(gè)極為龐大的數(shù)字。如果他們都去一個(gè)指定的地方下載數(shù)據(jù)，成千上萬(wàn)的真實(shí) IP 地址連接過(guò)來(lái)，沒(méi)有哪個(gè)設(shè)備能夠支撐住。拿 BT 下載來(lái)說(shuō)，偽造一些熱門(mén)視頻的種子，發(fā)布到搜索引擎，就足以騙到許多用戶(hù)和流量了，但是這只是基礎(chǔ)攻擊。高級(jí)的 P2P 攻擊，是直接欺騙資源管理服務(wù)器。如迅雷客戶(hù)端會(huì)把自己發(fā)現(xiàn)的資源上傳到資源管理服務(wù)器，然后推送給其它需要下載相同資源的用戶(hù)，這樣，一個(gè)鏈接就發(fā)布出去。通過(guò)協(xié)議逆向，攻擊者偽造出大批量的熱門(mén)資源信息通過(guò)資源管理中心分發(fā)出去，瞬間就可以傳遍整個(gè) P2P 網(wǎng)絡(luò)。更為恐怖的是，這種攻擊是無(wú)法停止的，即使是攻擊者自身也無(wú)法停止，攻擊一直持續(xù)到 P2P 官方發(fā)現(xiàn)問(wèn)題更新服務(wù)器且下載用戶(hù)重啟下載軟件為止。

流量劫持應(yīng)該算是黑產(chǎn)行業(yè)的一大經(jīng)濟(jì)支柱了吧？簡(jiǎn)直是讓人惡心到吐，不吐槽了，還是繼續(xù)談干貨吧，流量劫持基本分兩種：DNS 劫持 和 HTTP 劫持，目的都是一樣的，就是當(dāng)用戶(hù)訪問(wèn) zoumiaojiang.com 的時(shí)候，給你展示的并不是或者不完全是zoumiaojiang.com 提供的 “內(nèi)容”。

DNS 劫持，也叫做域名劫持，可以這么理解，「你打了一輛車(chē)想去商場(chǎng)吃飯，結(jié)果你打的車(chē)是小作坊派來(lái)的，直接給你拉到小作坊去了」，DNS 的作用是把網(wǎng)絡(luò)地址域名對(duì)應(yīng)到真實(shí)的計(jì)算機(jī)能夠識(shí)別的 IP 地址，以便計(jì)算機(jī)能夠進(jìn)一步通信，傳遞網(wǎng)址和內(nèi)容等。如果當(dāng)用戶(hù)通過(guò)某一個(gè)域名訪問(wèn)一個(gè)站點(diǎn)的時(shí)候，被篡改的 DNS 服務(wù)器返回的是一個(gè)惡意的釣魚(yú)站點(diǎn)的 IP，用戶(hù)就被劫持到了惡意釣魚(yú)站點(diǎn)，然后繼而會(huì)被釣魚(yú)輸入各種賬號(hào)密碼信息，泄漏隱私。

這類(lèi)劫持，要不就是網(wǎng)絡(luò)運(yùn)營(yíng)商搞的鬼，一般小的網(wǎng)絡(luò)運(yùn)營(yíng)商與黑產(chǎn)勾結(jié)會(huì)劫持 DNS，要不就是電腦中毒，被惡意篡改了路由器的 DNS 配置，基本上做為開(kāi)發(fā)者或站長(zhǎng)卻是很難察覺(jué)的，除非有用戶(hù)反饋，現(xiàn)在升級(jí)版的 DNS 劫持還可以對(duì)特定用戶(hù)、特定區(qū)域等使用了用戶(hù)畫(huà)像進(jìn)行篩選用戶(hù)劫持的辦法，另外這類(lèi)廣告顯示更加隨機(jī)更小，一般站長(zhǎng)除非用戶(hù)投訴否則很難覺(jué)察到，就算覺(jué)察到了取證舉報(bào)更難。無(wú)論如何，如果接到有 DNS 劫持的反饋，一定要做好以下幾件事：

如果你的系統(tǒng)是有登錄控制的，那就要格外小心了，因?yàn)楹苡锌赡苣愕南到y(tǒng)越權(quán)操作漏洞，越權(quán)操作漏洞可以簡(jiǎn)單的總結(jié)為 「A 用戶(hù)能看到或者操作 B 用戶(hù)的隱私內(nèi)容」，如果你的系統(tǒng)中還有權(quán)限控制就更加需要小心了。所以每一個(gè)請(qǐng)求都需要做 userid 的判斷

以下是一段有漏洞的后端示意代碼：

以上代碼是任何人都可以查詢(xún)到任何用戶(hù)的消息，只要有 msg_id 就可以，這就是比較典型的越權(quán)漏洞，需要如下這么改進(jìn)一下：

你想要將 static 的文件夾配成靜態(tài)資源目錄，你應(yīng)該會(huì)在 server.js 做如下配置：

但是如果配錯(cuò)了靜態(tài)資源的目錄，可能就出大事了，比如：

這樣所有的源代碼都可以通過(guò)路由訪問(wèn)到了，所有的服務(wù)器都提供了靜態(tài)資源機(jī)制，所以在通過(guò)服務(wù)器配置靜態(tài)資源目錄和路徑的時(shí)候，一定要注意檢驗(yàn)，不然很可能產(chǎn)生漏洞。

最后，希望 Web 開(kāi)發(fā)者們能夠管理好自己的代碼隱私，注意代碼安全問(wèn)題，比如不要將產(chǎn)品的含有敏感信息的代碼放到第三方外部站點(diǎn)或者暴露給外部用戶(hù)，尤其是前端代碼，私鑰類(lèi)似的保密性的東西不要直接輸出在代碼里或者頁(yè)面中。也許還有很多值得注意的點(diǎn)，但是歸根結(jié)底還是繃住安全那根弦，對(duì)待每一行代碼都要多多推敲。

作者：江哥亂談