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

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

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

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

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

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

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

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

避免方法：

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

這時候需要通過以下方式來防止這類漏洞：

完成 CSRF 攻擊必須要有三個條件：

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

當正確的使用了 GET 和 POST 請求之后，剩下的就是在非 GET 方式的請求中增加隨機數(shù)，這個大概有三種方式來進行：

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

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

而造成 SQL 注入的原因是因為程序沒有有效的轉義過濾用戶的輸入，使攻擊者成功的向服務器提交惡意的 SQL 查詢代碼，程序在接收后錯誤的將攻擊者的輸入作為查詢語句的一部分執(zhí)行，導致原始的查詢邏輯被改變，額外的執(zhí)行了攻擊者精心構造的惡意代碼。

很多 Web 開發(fā)者沒有意識到 SQL 查詢是可以被篡改的，從而把 SQL 查詢當作可信任的命令。殊不知，SQL 查詢是可以繞開訪問控制，從而繞過身份驗證和權限檢查的。更有甚者，有可能通過 SQL 查詢去運行主機系統(tǒng)級的命令。

下面將通過一些真實的例子來詳細講解 SQL 注入的方式的原理。

考慮以下簡單的管理員登錄表單：

后端的 SQL 語句可能是如下這樣的：

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

冷靜下來思考一下，我們之前預想的真實 SQL 語句是:

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

在 SQL 中，-- 是注釋后面的內容的意思，所以查詢語句就變成了：

這條 SQL 語句的查詢條件永遠為真，所以意思就是惡意攻擊者不用我的密碼，就可以登錄進我的賬號，然后可以在里面為所欲為，然而這還只是最簡單的注入，牛逼 的 SQL 注入高手甚至可以通過 SQL 查詢去運行主機系統(tǒng)級的命令，將你主機里的內容一覽無余，這里我也沒有這個能力講解的太深入，畢竟不是專業(yè)研究這類攻擊的，但是通過以上的例子，已經了解了 SQL 注入的原理，我們基本已經能找到防御 SQL 注入的方案了。

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

命令行注入漏洞，指的是攻擊者能夠通過 HTTP 請求直接侵入主機，執(zhí)行攻擊者預設的 shell 命令，聽起來好像匪夷所思，這往往是 Web 開發(fā)者最容易忽視但是卻是最危險的一個漏洞之一，看一個實例：

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

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

ICMP Flood 攻擊

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

利用 XSS

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

來自 P2P 網絡攻擊

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

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

DNS 劫持，也叫做域名劫持，可以這么理解，「你打了一輛車想去商場吃飯，結果你打的車是小作坊派來的，直接給你拉到小作坊去了」，DNS 的作用是把網絡地址域名對應到真實的計算機能夠識別的 IP 地址，以便計算機能夠進一步通信，傳遞網址和內容等。如果當用戶通過某一個域名訪問一個站點的時候，被篡改的 DNS 服務器返回的是一個惡意的釣魚站點的 IP，用戶就被劫持到了惡意釣魚站點，然后繼而會被釣魚輸入各種賬號密碼信息，泄漏隱私。

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

如果你的系統(tǒng)是有登錄控制的，那就要格外小心了，因為很有可能你的系統(tǒng)越權操作漏洞，越權操作漏洞可以簡單的總結為 「A 用戶能看到或者操作 B 用戶的隱私內容」，如果你的系統(tǒng)中還有權限控制就更加需要小心了。所以每一個請求都需要做 userid 的判斷

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

以上代碼是任何人都可以查詢到任何用戶的消息，只要有 msg_id 就可以，這就是比較典型的越權漏洞，需要如下這么改進一下：

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

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

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

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

作者：江哥亂談