摘要：跨站腳本攻擊的全稱是，意為跨站腳本攻擊，為了區(qū)別于而特意寫(xiě)成。這一攻擊方法也是很常見(jiàn)的攻擊之一，而且由于需要在寫(xiě)的時(shí)候特別注意，這一攻擊往往容易被忽略。隱蔽性高是這一攻擊最大的特點(diǎn)。

發(fā)布自Kindem的博客，歡迎大家轉(zhuǎn)載，但是要注意注明出處。另外，該文章收納在Kindem的個(gè)人的 IT 知識(shí)整理倉(cāng)庫(kù)，歡迎 Star、Fork、投稿

這一點(diǎn)可能都被說(shuō)爛了，只要是動(dòng)態(tài)網(wǎng)站，可以說(shuō)基本上第一個(gè)必須考慮的點(diǎn)就是SQL注入。

那什么是SQL注入呢，先舉一個(gè)例子吧：

這是一個(gè)典型的登錄場(chǎng)景：

--------------------------------
|  Username:                   |
--------------------------------
|  Password:                   |
--------------------------------

網(wǎng)站要求用戶輸入用戶名和密碼以登錄，這時(shí)候通常后端的SQL語(yǔ)句是：

select * from user_t where
    user_t.username = "..." and
    user_t.password = "...";

看起來(lái)好像沒(méi)有什么問(wèn)題，當(dāng)獲取到匹配用戶名和密碼的表項(xiàng)時(shí)，判斷結(jié)果集的數(shù)量是否為1，再進(jìn)行一些其他的邏輯判斷，即可判定用戶成功登陸，但是吧，這樣會(huì)有一個(gè)問(wèn)題，如果后端代碼采用了字符串拼接，這里將出現(xiàn)一個(gè)致命的問(wèn)題：

比如我按照如下方式輸入：

--------------------------------
|  Username: John Kindem"; --  |
--------------------------------
|  Password: mypassword        |
--------------------------------

此時(shí)SQL語(yǔ)句就會(huì)變成：

select * from user_t where
    user_t.username = "John Kindem"; --" and
    user_t.password = "...";

整理一下，就會(huì)變成這樣：

select * from user_t where
    user_t.username = "John Kindem";
--" and user_t.password = "...";

可見(jiàn)原本密碼這一條件，直接被注釋掉了，而原來(lái)的SQL語(yǔ)句被提前結(jié)束了，這樣你隨意使用一個(gè)密碼就能登錄為站點(diǎn)任意一個(gè)用戶，是不是很恐怖，設(shè)想一下，假如這個(gè)框中包含有管理員用戶的登錄功能，這一條語(yǔ)句將毀掉多少數(shù)據(jù)......

所以這就是SQL注入，這一點(diǎn)往往是Web開(kāi)發(fā)中最危險(xiǎn)的一個(gè)點(diǎn)，由于其往往與權(quán)限有關(guān)，一旦被攻破就會(huì)導(dǎo)致數(shù)據(jù)庫(kù)遭到破壞或者是站點(diǎn)控制權(quán)的丟失。

SQL注入往往通過(guò)構(gòu)建特殊的輸入來(lái)進(jìn)行，這些特殊的輸入往往有以下的想法：

提前結(jié)束SQL語(yǔ)句

注釋掉SQL語(yǔ)句的一部分

使用布爾表達(dá)式構(gòu)造恒等式

在原有SQL語(yǔ)句中加入自己的插入、刪除、修改等SQL語(yǔ)句

SQL的防范其實(shí)也很好做，在現(xiàn)代的Web開(kāi)發(fā)中，往往遵循以下幾條規(guī)則開(kāi)發(fā)就能很好地避免被SQL注入：

不要隨意對(duì)SQL語(yǔ)句使用字符串拼接

使用預(yù)編譯的方法來(lái)使用SQL語(yǔ)句

對(duì)于后者，基本上所有的語(yǔ)言都支持這一點(diǎn)，拿JavaScript來(lái)說(shuō)：

// Nodejs 連接 MySQL 進(jìn)行查詢
connection.query("select * from student where id = ?", 5, () => {
    ...
});

這樣可以查詢到 student 表中 id = 5 的表項(xiàng)的所有信息，但同時(shí)能夠防范SQL注入，因?yàn)檫@樣的語(yǔ)句在使用之前就會(huì)被預(yù)編譯，你無(wú)法再隨意改變SQL語(yǔ)句的構(gòu)成。

XSS的全稱是 Cross Site Scripting，意為跨站腳本攻擊，為了區(qū)別于 CSS (Cascading Style Sheets) 而特意寫(xiě)成 XSS。這一攻擊方法也是很常見(jiàn)的Web攻擊之一，而且由于需要在寫(xiě) JavaScript 的時(shí)候特別注意，這一攻擊往往容易被忽略。

當(dāng)然隨著前端的發(fā)展，現(xiàn)在這一攻擊的防范方法往往都會(huì)被集成在框架中，比如 React、Vue 中，很多地方就集成了 XSS 防范，你在使用框架的時(shí)候，很多地方往往都不需要注意這一點(diǎn)，框架往往幫你做了防護(hù)。

這里簡(jiǎn)單介紹一下 XSS，先舉一個(gè)例子：

現(xiàn)在有這樣一個(gè)博客網(wǎng)站：

寫(xiě)博客頁(yè)面提供一個(gè)富文本編輯器，用于給用戶寫(xiě)博客

看博客頁(yè)面獲取用戶寫(xiě)的博客，并且將富文本編輯器產(chǎn)生的html文本顯示在頁(yè)面上

那么，假如用戶在富文本編輯器上寫(xiě)：

hello world

富文本編輯器的原理往往是將用戶輸入的內(nèi)容轉(zhuǎn)義成帶有格式的html文本并且輸出，很有可能它的輸出結(jié)果是這樣的：

    hello world
    

想想看，如果這樣的一段文本，如果原封不動(dòng)地被顯示在看博客的頁(yè)面，會(huì)導(dǎo)致什么？

很顯然，其中的 script 標(biāo)簽中的內(nèi)容，將會(huì)直接被當(dāng)成腳本執(zhí)行，想想這會(huì)有很危險(xiǎn)，有心的攻擊者可以利用這一漏洞，隨心所欲地寫(xiě)自己的攻擊腳本，比如獲取用戶的 cookie、進(jìn)行惡意請(qǐng)求、監(jiān)聽(tīng)用戶輸入等......

這就是 XSS，在平日寫(xiě) JavaScript 的過(guò)程中很容易就會(huì)產(chǎn)生這一的漏洞，XSS 的生效往往有兩個(gè)條件：

構(gòu)建惡意輸入，使得輸入中包含惡意的 JavaScript、html 代碼

頁(yè)面原有的代碼會(huì)將這些輸入不經(jīng)處理地直接當(dāng)成頁(yè)面、原有代碼的一部分

最簡(jiǎn)單的例子，就是網(wǎng)站直接將用戶的輸入作為輸出顯示在頁(yè)面上，再或者，站點(diǎn)中有一些 eval() 之類的函數(shù)，能夠直接執(zhí)行用戶輸入......

當(dāng)然 XSS 的防范也不是不無(wú)方法可循，最重要的一點(diǎn)是：

永遠(yuǎn)不要信任用戶的輸入，如果需要將用戶的輸入用在頁(yè)面或者代碼中，一定要轉(zhuǎn)義

轉(zhuǎn)義這一點(diǎn)，講的是針對(duì)那些能夠影響到原有代碼的特殊符號(hào)，比如 <、> 等，這里給出一些常用的轉(zhuǎn)義規(guī)則：

---------------------
|    <    |  <   |
---------------------
|    >    |  >   |
---------------------
|    "    |  &  |
---------------------
|    "    |  " |
---------------------

進(jìn)行完轉(zhuǎn)義之后，這些字符會(huì)被當(dāng)成普通顯示的字符，而不是具有特殊意義的字符

CSRF 全稱為 Cross Site Request Forgery，即跨域請(qǐng)求偽造。這一點(diǎn)攻擊往往容易被人一樓，在一些老一些的網(wǎng)站，基本上都沒(méi)有考慮到這一點(diǎn)，就連百度、亞馬遜這一些大型網(wǎng)站，在 CSRF 被人大規(guī)模利用進(jìn)行攻擊之前甚至都沒(méi)有做這一方面的防范。隱蔽性高是這一攻擊最大的特點(diǎn)。

這一攻擊主要利用的是網(wǎng)站對(duì)用戶身份的絕對(duì)信任，CSRF 有一些難以理解，這里用一個(gè)例子簡(jiǎn)單地說(shuō)清楚：

舉一個(gè)例子，現(xiàn)在這里有一個(gè)網(wǎng)購(gòu)網(wǎng)站，一般來(lái)說(shuō)，往往當(dāng)用戶登錄之后，驗(yàn)證了身份后，站點(diǎn)在一次會(huì)話結(jié)束前，都是信任用戶的，也就是說(shuō)，站點(diǎn)相信用戶是本人，但是吧，現(xiàn)在有這樣一次操作：

用戶先登錄了網(wǎng)購(gòu)網(wǎng)站

用戶沒(méi)有關(guān)閉網(wǎng)購(gòu)網(wǎng)站的標(biāo)簽頁(yè)，打開(kāi)了另外一個(gè)網(wǎng)站

那一個(gè)網(wǎng)站是一個(gè)惡意網(wǎng)站，登錄那個(gè)網(wǎng)站的一刻，它向網(wǎng)購(gòu)網(wǎng)站發(fā)送了一個(gè)購(gòu)買物品請(qǐng)求

現(xiàn)在想一想，會(huì)出現(xiàn)什么問(wèn)題？由于用戶沒(méi)有關(guān)閉網(wǎng)購(gòu)網(wǎng)站的標(biāo)簽頁(yè)，上一次會(huì)話并沒(méi)有結(jié)束，惡意網(wǎng)站發(fā)送的請(qǐng)求的 cookie 中將會(huì)帶有與上一次會(huì)話相同的 sessionId，也就是說(shuō)在網(wǎng)購(gòu)網(wǎng)站的那一端將會(huì)認(rèn)為這一次請(qǐng)求任然是用戶的請(qǐng)求，所以會(huì)欣然接受。

是不是很可怕？你明明沒(méi)有做任何操作，你的一切卻已經(jīng)屬于了別人。很多時(shí)候，被 CSRF 攻擊之后，用戶往往都不知道發(fā)生了什么，自己的錢包就空了。CSRF 最可怕的地方就在于這里，它的攻擊目標(biāo)往往不是站點(diǎn)，而是站點(diǎn)的用戶，再者，它的隱蔽性也讓人忌憚。

CSRF 的防范，也是有規(guī)律可循的，最重要的一點(diǎn)是，站點(diǎn)永遠(yuǎn)不要信任任何一個(gè)用戶，需要對(duì)用戶進(jìn)行時(shí)刻驗(yàn)證，一般來(lái)說(shuō)現(xiàn)在都是這樣操作的：

在每一次請(qǐng)求中，都帶著雙方按照一定約定產(chǎn)生的一個(gè)隨機(jī) Token，這一個(gè) Token 可以通過(guò)公鑰加密或者其他的方法產(chǎn)生，Token 驗(yàn)證通過(guò)了才說(shuō)明是用戶本人

在平時(shí)我們的開(kāi)發(fā)中，往往靜態(tài)資源的命名都是有規(guī)律的，比如吧，一些同一頁(yè)面引用的js腳本，會(huì)被我們?nèi)绱嗣?/p>

index-script-1.js

index-script-2.js

index-script-3.js

...

同樣的，圖片、CSS 文件都會(huì)像這樣命名，有心人就可以寫(xiě)一個(gè)腳本，遍歷整個(gè)站點(diǎn)目錄，獲取一些文件。當(dāng)然，這些靜態(tài)文件給他也無(wú)妨，畢竟你摁 F12 也是一樣的效果......

但是設(shè)想一下，假如站點(diǎn)文件服務(wù)器上有一些特殊的文件，比如哪一個(gè)傻傻的開(kāi)發(fā)者使用 bak 格式備份了某一個(gè)后端文件，但是忘了刪除然后一直存在了服務(wù)器上，比如：

index-backend.php.bak

index-login-backend.php.bak

這些文件要是給弄到了，相當(dāng)于網(wǎng)站的后端邏輯直接暴露在了用戶面前，有心人就可以通過(guò)這些文件來(lái)分析獲取該站點(diǎn)的一些漏洞。

總的來(lái)說(shuō)危害還是不大，但是平日里一定要注意：

不要把任何后端有關(guān)的文件仍在服務(wù)器上

文件使用 UUID 或者其他方法隨機(jī)命名使之沒(méi)有規(guī)律，加大枚舉難度

跨域問(wèn)題，自如其名，就是在站點(diǎn)域外獲取站點(diǎn)的服務(wù)，這樣的危害其實(shí)不是很大，因?yàn)檎军c(diǎn)一般都有訪問(wèn)控制，每一個(gè)身份都有自己能做的事情和不能做的事情，而且一般來(lái)說(shuō)，瀏覽器和框架對(duì)這一攻擊都有著嚴(yán)格的防范，基本上來(lái)說(shuō)，非本域下的請(qǐng)求基本上不可能成功。

但是吧這里還是提一句吧，還是以一個(gè)例子來(lái)說(shuō)明：

假如我得知了一個(gè)站點(diǎn)的注冊(cè)用戶的請(qǐng)求 url 和其參數(shù)列表，并且我發(fā)現(xiàn)它沒(méi)有設(shè)定訪問(wèn)控制和非本域請(qǐng)求禁止

我直接直接寫(xiě)一個(gè)腳本，按照它的格式瘋狂發(fā)送 http 請(qǐng)求，或者說(shuō)操控一大批傀儡機(jī)，不斷注冊(cè)，影響站點(diǎn)的正常工作

雖然一般是不太可能成功的......但是我們還是假設(shè)站點(diǎn)真的傻到這種地步

跨域問(wèn)題一般通過(guò)使用 http response header 中的 Access-Control-Allow-Origin 來(lái)防范，這一字段可以聲明該 response 允許的域，比如：

Access-Control-Allow-Origin: www.kindemh.cn

那么非本域的所有請(qǐng)求，就算你請(qǐng)求了，你也無(wú)法獲取到 response

這里值得一提的是，在現(xiàn)代開(kāi)發(fā)中，我們往往會(huì)使用 Ajax 技術(shù)來(lái)發(fā)送異步請(qǐng)求，但是實(shí)際上，如果你使用 Ajax 技術(shù)，十有八九都會(huì)因?yàn)榭缬蛳拗票粩r截，這時(shí)候你就需要使用上述字段來(lái)允許你自己的服務(wù)。所以說(shuō)這一點(diǎn)其實(shí)本來(lái)沒(méi)多大危害，要說(shuō)真正的危害，還是對(duì)你的開(kāi)發(fā)效率會(huì)造成一定的影響。