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

發布自Kindem的博客，歡迎大家轉載，但是要注意注明出處。另外，該文章收納在Kindem的個人的 IT 知識整理倉庫，歡迎 Star、Fork、投稿

這一點可能都被說爛了，只要是動態網站，可以說基本上第一個必須考慮的點就是SQL注入。

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

這是一個典型的登錄場景：

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

網站要求用戶輸入用戶名和密碼以登錄，這時候通常后端的SQL語句是：

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

看起來好像沒有什么問題，當獲取到匹配用戶名和密碼的表項時，判斷結果集的數量是否為1，再進行一些其他的邏輯判斷，即可判定用戶成功登陸，但是吧，這樣會有一個問題，如果后端代碼采用了字符串拼接，這里將出現一個致命的問題：

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

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

此時SQL語句就會變成：

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

整理一下，就會變成這樣：

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

可見原本密碼這一條件，直接被注釋掉了，而原來的SQL語句被提前結束了，這樣你隨意使用一個密碼就能登錄為站點任意一個用戶，是不是很恐怖，設想一下，假如這個框中包含有管理員用戶的登錄功能，這一條語句將毀掉多少數據......

所以這就是SQL注入，這一點往往是Web開發中最危險的一個點，由于其往往與權限有關，一旦被攻破就會導致數據庫遭到破壞或者是站點控制權的丟失。

SQL注入往往通過構建特殊的輸入來進行，這些特殊的輸入往往有以下的想法：

提前結束SQL語句

注釋掉SQL語句的一部分

使用布爾表達式構造恒等式

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

SQL的防范其實也很好做，在現代的Web開發中，往往遵循以下幾條規則開發就能很好地避免被SQL注入：

不要隨意對SQL語句使用字符串拼接

使用預編譯的方法來使用SQL語句

對于后者，基本上所有的語言都支持這一點，拿JavaScript來說：

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

這樣可以查詢到 student 表中 id = 5 的表項的所有信息，但同時能夠防范SQL注入，因為這樣的語句在使用之前就會被預編譯，你無法再隨意改變SQL語句的構成。

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

當然隨著前端的發展，現在這一攻擊的防范方法往往都會被集成在框架中，比如 React、Vue 中，很多地方就集成了 XSS 防范，你在使用框架的時候，很多地方往往都不需要注意這一點，框架往往幫你做了防護。

這里簡單介紹一下 XSS，先舉一個例子：

現在有這樣一個博客網站：

寫博客頁面提供一個富文本編輯器，用于給用戶寫博客

看博客頁面獲取用戶寫的博客，并且將富文本編輯器產生的html文本顯示在頁面上

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

hello world

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

    hello world
    

想想看，如果這樣的一段文本，如果原封不動地被顯示在看博客的頁面，會導致什么？

很顯然，其中的 script 標簽中的內容，將會直接被當成腳本執行，想想這會有很危險，有心的攻擊者可以利用這一漏洞，隨心所欲地寫自己的攻擊腳本，比如獲取用戶的 cookie、進行惡意請求、監聽用戶輸入等......

這就是 XSS，在平日寫 JavaScript 的過程中很容易就會產生這一的漏洞，XSS 的生效往往有兩個條件：

構建惡意輸入，使得輸入中包含惡意的 JavaScript、html 代碼

頁面原有的代碼會將這些輸入不經處理地直接當成頁面、原有代碼的一部分

最簡單的例子，就是網站直接將用戶的輸入作為輸出顯示在頁面上，再或者，站點中有一些 eval() 之類的函數，能夠直接執行用戶輸入......

當然 XSS 的防范也不是不無方法可循，最重要的一點是：

永遠不要信任用戶的輸入，如果需要將用戶的輸入用在頁面或者代碼中，一定要轉義

轉義這一點，講的是針對那些能夠影響到原有代碼的特殊符號，比如 <、> 等，這里給出一些常用的轉義規則：

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

進行完轉義之后，這些字符會被當成普通顯示的字符，而不是具有特殊意義的字符

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

這一攻擊主要利用的是網站對用戶身份的絕對信任，CSRF 有一些難以理解，這里用一個例子簡單地說清楚：

舉一個例子，現在這里有一個網購網站，一般來說，往往當用戶登錄之后，驗證了身份后，站點在一次會話結束前，都是信任用戶的，也就是說，站點相信用戶是本人，但是吧，現在有這樣一次操作：

用戶先登錄了網購網站

用戶沒有關閉網購網站的標簽頁，打開了另外一個網站

那一個網站是一個惡意網站，登錄那個網站的一刻，它向網購網站發送了一個購買物品請求

現在想一想，會出現什么問題？由于用戶沒有關閉網購網站的標簽頁，上一次會話并沒有結束，惡意網站發送的請求的 cookie 中將會帶有與上一次會話相同的 sessionId，也就是說在網購網站的那一端將會認為這一次請求任然是用戶的請求，所以會欣然接受。

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

CSRF 的防范，也是有規律可循的，最重要的一點是，站點永遠不要信任任何一個用戶，需要對用戶進行時刻驗證，一般來說現在都是這樣操作的：

在每一次請求中，都帶著雙方按照一定約定產生的一個隨機 Token，這一個 Token 可以通過公鑰加密或者其他的方法產生，Token 驗證通過了才說明是用戶本人

在平時我們的開發中，往往靜態資源的命名都是有規律的，比如吧，一些同一頁面引用的js腳本，會被我們如此命名：

index-script-1.js

index-script-2.js

index-script-3.js

...

同樣的，圖片、CSS 文件都會像這樣命名，有心人就可以寫一個腳本，遍歷整個站點目錄，獲取一些文件。當然，這些靜態文件給他也無妨，畢竟你摁 F12 也是一樣的效果......

但是設想一下，假如站點文件服務器上有一些特殊的文件，比如哪一個傻傻的開發者使用 bak 格式備份了某一個后端文件，但是忘了刪除然后一直存在了服務器上，比如：

index-backend.php.bak

index-login-backend.php.bak

這些文件要是給弄到了，相當于網站的后端邏輯直接暴露在了用戶面前，有心人就可以通過這些文件來分析獲取該站點的一些漏洞。

總的來說危害還是不大，但是平日里一定要注意：

不要把任何后端有關的文件仍在服務器上

文件使用 UUID 或者其他方法隨機命名使之沒有規律，加大枚舉難度

跨域問題，自如其名，就是在站點域外獲取站點的服務，這樣的危害其實不是很大，因為站點一般都有訪問控制，每一個身份都有自己能做的事情和不能做的事情，而且一般來說，瀏覽器和框架對這一攻擊都有著嚴格的防范，基本上來說，非本域下的請求基本上不可能成功。

但是吧這里還是提一句吧，還是以一個例子來說明：

假如我得知了一個站點的注冊用戶的請求 url 和其參數列表，并且我發現它沒有設定訪問控制和非本域請求禁止

我直接直接寫一個腳本，按照它的格式瘋狂發送 http 請求，或者說操控一大批傀儡機，不斷注冊，影響站點的正常工作

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

跨域問題一般通過使用 http response header 中的 Access-Control-Allow-Origin 來防范，這一字段可以聲明該 response 允許的域，比如：

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

那么非本域的所有請求，就算你請求了，你也無法獲取到 response

這里值得一提的是，在現代開發中，我們往往會使用 Ajax 技術來發送異步請求，但是實際上，如果你使用 Ajax 技術，十有八九都會因為跨域限制被攔截，這時候你就需要使用上述字段來允許你自己的服務。所以說這一點其實本來沒多大危害，要說真正的危害，還是對你的開發效率會造成一定的影響。