看了一些Web安全的文章，有些講得非常好，也非常詳細，但不夠言簡意賅；本文是個吸取了他們的精華之后總結(jié)，以清晰明了、言簡意賅為目的。
目錄
- 1. XSS (Cross Site Script) 跨站腳本攻擊
- 2. CSRF（Cross-Site Request Forgery）跨站請求偽造攻擊
- 3. SQL 注入
- 4. 點擊劫持
- 5. 命令行注入
- 6. DNS劫持
- 7. HTTP劫持
內(nèi)容
1. XSS (Cross Site Script) 跨站腳本攻擊
1.1. 示例
如你的 Web 頁面中有如下類似的代碼：
document.write(
"" +
"<div >" +
location.href.substring(location.href.indexOf("default=") + 8) +
"</div>"
);
攻擊者可以直接通過 URL 注入可執(zhí)行的腳本代碼，如：https://xx.com/xx?default=<script>alert(document.cookie)</script>；
1.2. 原理
當頁面有動態(tài)渲染 或 執(zhí)行的內(nèi)容（比如通過：eval、document.write()、innerHTML），且并未對未渲染的內(nèi)容做轉(zhuǎn)義時，就可以通過注入帶有可執(zhí)行腳本的內(nèi)容（如：<script></script>）來運行惡意代碼；
1.3. 解決方案
- 從源頭：盡量從自已的服務端獲取數(shù)據(jù)來源，盡量不要從
location、document.referrer、document.forms等這種可被外部操作的 Api 中獲取數(shù)據(jù)直接渲染。 - 從出口：在將內(nèi)容渲染至 dom 中時，一律對內(nèi)容的 HTML 關(guān)鍵字進行轉(zhuǎn)義（如：
<>）。
2. CSRF（Cross-Site Request Forgery）跨站請求偽造攻擊
2.1. 原理
完成 CSRF 攻擊必須具備以下條件：
- 瀏覽器中保存了 站點 A 的 cookie，并且 cookie 還沒失效；
- 用戶訪問了惡意 站點 B
- 惡意站點 B 可向 A 站點的服務器發(fā)送請求，并會自動攜帶上 站點 A 的 cookie；
- 站點 A 沒有做任何 CSRF 攻擊防御；
2.2. 解決方案
- 為每個用戶生成一個唯一的 token，該 token 不是通過 cookie 的方式返回給 用戶，用戶在每次請求時帶上該 token；后端收到請求后，驗證 token；
3. SQL 注入
3.1. 示例
假設(shè)：
用戶的登錄表單：
<form action="/login" method="POST">
<p>用戶名: <input type="text" name="username" /></p>
<p>密碼: <input type="password" name="password" /></p>
<p><input type="submit" value="登陸" /></p>
</form>
后端查詢用戶的 SQL 語句：
let querySQL = `
SELECT * FROM user
WHERE username='${username}'
AND psw='${password}'
`;
// 接下來就是執(zhí)行 sql 語句...
則：
當惡意攻擊者輸入的用戶名是 zoumiaojiang' OR 1 = 1 -- 時，密碼隨意輸入，就可以直接登入系統(tǒng)了；
因為這會使得最終生成的 SQL 語法為：
SELECT * FROM user WHERE username='zoumiaojiang' OR 1 = 1 --' AND psw='xxxx'
在 SQL 中，-- 是注釋的意思，所以查詢語句就變成了：
SELECT * FROM user WHERE username='zoumiaojiang' OR 1 = 1
這條 SQL 語句的查詢條件永遠為真，所以意思就是惡意攻擊者輸入正確的密碼，就可以登錄進賬號；
3.2. 解決方案
- 對于需要通過參數(shù)拼接的生成數(shù)據(jù)庫語句的情況，要對參數(shù)進行 SQL 關(guān)鍵字檢查、轉(zhuǎn)義、過濾。
- 使用數(shù)據(jù)庫提供的參數(shù)化接口來進行數(shù)據(jù)庫的操作，而不是通過拼接數(shù)據(jù)庫語句。
4. 點擊劫持
4.1. 示例
假如惡意者想誘騙用戶為其在博客的發(fā)布的某個文章點贊，那么他可以將他的博客文章用 iframe 嵌入自己設(shè)計的網(wǎng)頁中，然后 iframe 元素層級下面 與 文章點贊按鈕對應的位置上放一個誘導性按鈕，然后將 iframe 設(shè)置為透明，這樣用戶就看不到 iframe 了，但能看到那個誘導性按鈕，當用戶點擊 誘導性按鈕 時，其實是點擊了 iframe 中文章點贊的按鈕；
4.2. 解決方案
- 在 HTTP 響應頭中增加
X-FRAME-OPTIONS字段，并將該字段設(shè)置為以下幾種值：-
DENY：表示頁面不允許通過 iframe 的方式展示 -
SAMEORIGIN：表示頁面可以在相同域名下通過 iframe 的方式展示 -
ALLOW-FROM：表示頁面可以在指定來源的 iframe 中展示
-
- 通過 js
self == top判斷當前頁面是否運行在 iframe，如果運行在 iframe，則可能通過 js 禁止一些操作 或 把整個頁面給移除掉；
5. 命令行注入
5.1. 示例
原理和 SQL注入 類似，就是：服務器要執(zhí)行命令，但命令是通過請求參數(shù)拼接而成的，就會存在被注入惡意命令的風險；
如下：
// 以 Node.js 為例，假如在接口中需要從 github 下載用戶指定的 repo
const exec = require('mz/child_process').exec;
let params = `用戶輸入的參數(shù)`;
exec(`git clone ${params} /some/path`);
如果用戶輸入的參數(shù)是 https://github.com/xx/xx.git && rm -rf /* &&，則最終會執(zhí)行的命令是 git clone https://github.com/xx/xx.git && rm -rf /* && some/path
5.2. 解決方案
解決方案也和 SQL注入 類似：
- 對于需要通過參數(shù)拼接的生成命令的情況，要對參數(shù)進行 命令 關(guān)鍵字檢查、轉(zhuǎn)義、過濾。
6. DNS劫持
6.1. 原理
通過篡改電腦 或 路由器的 DNS ，來讓一個域名 映射到一個惡意網(wǎng)站上，當你通過域名訪問網(wǎng)站時，其實訪問的是惡意網(wǎng)站；
7. HTTP劫持
在網(wǎng)絡(luò)請求鏈接中的某一個環(huán)境上（比如：路由器 或 運營商），攔截 HTTP 的響應，然后篡改響應體 或 在響應體內(nèi)插入內(nèi)容（比如：廣告）
