前言
在網際網路時代，資料安全與個人隱私受到了前所未有的挑戰，各種新奇的攻擊技術層出不窮。如何才能更好地保護我們的資料？本文主要側重於分析幾種常見的攻擊的型別以及防禦的方法。
一、XSS
XSS (Cross-Site Scripting)，跨站指令碼攻擊，因為縮寫和 CSS重疊，所以只能叫 XSS。跨站指令碼攻擊是指通過存在安全漏洞的Web網站註冊使用者的瀏覽器內執行非法的HTML標籤或JavaScript進行的一種攻擊。
跨站指令碼攻擊有可能造成以下影響:
- 利用虛假輸入表單騙取使用者個人資訊。
- 利用指令碼竊取使用者的Cookie值，被害者在不知情的情況下，幫助攻擊者傳送惡意請求。
- 顯示偽造的文章或圖片。
XSS 的原理是惡意攻擊者往 Web 頁面裡插入惡意可執行網頁尾本程式碼，當使用者瀏覽該頁之時，嵌入其中 Web 裡面的指令碼程式碼會被執行，從而可以達到攻擊者盜取使用者資訊或其他侵犯使用者安全隱私的目的。
XSS 的攻擊方式千變萬化，但還是可以大致細分為幾種型別。
1.非持久型 XSS（反射型 XSS ）
非持久型 XSS 漏洞，一般是通過給別人傳送帶有惡意指令碼程式碼引數的 URL，當 URL 地址被開啟時，特有的惡意程式碼引數被 HTML 解析、執行。
舉一個例子，比如頁面中包含有以下程式碼：
|
1 2 3 4 5 6 7 8 9 10 |
<select> <script> document.write('' + '<option value=1>' + location.href.substring(location.href.indexOf('default=') + 8) + '</option>' ); document.write('<option value=2>English</option>'); </script> </select> |
攻擊者可以直接通過 URL (類似：https://xxx.com/xxx?default=<script>alert(document.cookie)</script>) 注入可執行的指令碼程式碼。不過一些瀏覽器如Chrome其內建了一些XSS過濾器，可以防止大部分反射型XSS攻擊。
非持久型 XSS 漏洞攻擊有以下幾點特徵：
- 即時性，不經過伺服器儲存，直接通過 HTTP 的 GET 和 POST 請求就能完成一次攻擊，拿到使用者隱私資料。
- 攻擊者需要誘騙點選,必須要通過使用者點選連結才能發起
- 反饋率低，所以較難發現和響應修復
- 盜取使用者敏感保密資訊
為了防止出現非持久型 XSS 漏洞，需要確保這麼幾件事情：
- Web 頁面渲染的所有內容或者渲染的資料都必須來自於服務端。
- 儘量不要從
URL，document.referrer，document.forms等這種 DOM API 中獲取資料直接渲染。 - 儘量不要使用
eval,new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.createElement()等可執行字串的方法。 - 如果做不到以上幾點，也必須對涉及 DOM 渲染的方法傳入的字串引數做 escape 轉義。
- 前端渲染的時候對任何的欄位都需要做 escape 轉義編碼。
2.持久型 XSS（儲存型 XSS）
持久型 XSS 漏洞，一般存在於 Form 表單提交等互動功能，如文章留言，提交文字資訊等，黑客利用的 XSS 漏洞，將內容經正常功能提交進入資料庫持久儲存，當前端頁面獲得後端從資料庫中讀出的注入程式碼時，恰好將其渲染執行。
舉個例子，對於評論功能來說，就得防範持久型 XSS 攻擊，因為我可以在評論中輸入以下內容
主要注入頁面方式和非持久型 XSS 漏洞類似，只不過持久型的不是來源於 URL，referer，forms 等，而是來源於後端從資料庫中讀出來的資料 。持久型 XSS 攻擊不需要誘騙點選，黑客只需要在提交表單的地方完成注入即可，但是這種 XSS 攻擊的成本相對還是很高。
攻擊成功需要同時滿足以下幾個條件：
- POST 請求提交表單後端沒做轉義直接入庫。
- 後端從資料庫中取出資料沒做轉義直接輸出給前端。
- 前端拿到後端資料沒做轉義直接渲染成 DOM。
持久型 XSS 有以下幾個特點：
- 永續性，植入在資料庫中
- 盜取使用者敏感私密資訊
- 危害面廣
3.如何防禦
對於 XSS 攻擊來說，通常有兩種方式可以用來防禦。
1) CSP
CSP 本質上就是建立白名單，開發者明確告訴瀏覽器哪些外部資源可以載入和執行。我們只需要配置規則，如何攔截是由瀏覽器自己實現的。我們可以通過這種方式來儘量減少 XSS 攻擊。
通常可以通過兩種方式來開啟 CSP：
- 設定 HTTP Header 中的 Content-Security-Policy
- 設定 meta 標籤的方式
這裡以設定 HTTP Header 來舉例：
- 只允許載入本站資源
|
1 2 |
Content-Security-Policy: default-src 'self' |
- 只允許載入 HTTPS 協議圖片
|
1 2 |
Content-Security-Policy: img-src https://* |
- 允許載入任何來源框架
|
1 2 |
Content-Security-Policy: child-src 'none' |
如需瞭解更多屬性，請檢視Content-Security-Policy文件
對於這種方式來說，只要開發者配置了正確的規則，那麼即使網站存在漏洞，攻擊者也不能執行它的攻擊程式碼，並且 CSP 的相容性也不錯。
2) 轉義字元
使用者的輸入永遠不可信任的，最普遍的做法就是轉義輸入輸出的內容，對於引號、尖括號、斜槓進行轉義
|
1 2 3 4 5 6 7 8 9 10 |
function escape(str) { str = str.replace(/&/g, '&') str = str.replace(/</g, '<') str = str.replace(/>/g, '>') str = str.replace(/"/g, '&quto;') str = str.replace(/'/g, ''') str = str.replace(/`/g, '`') str = str.replace(/\//g, '/') return str } |
但是對於顯示富文字來說，顯然不能通過上面的辦法來轉義所有字元，因為這樣會把需要的格式也過濾掉。對於這種情況，通常採用白名單過濾的辦法，當然也可以通過黑名單過濾，但是考慮到需要過濾的標籤和標籤屬性實在太多，更加推薦使用白名單的方式。
|
1 2 3 4 |
const xss = require('xss') let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>') // -> <h1>XSS Demo</h1><script>alert("xss");</script> console.log(html) |
以上示例使用了 js-xss 來實現，可以看到在輸出中保留了 h1 標籤且過濾了 script 標籤。
3) HttpOnly Cookie。
這是預防XSS攻擊竊取使用者cookie最有效的防禦手段。Web應用程式在設定cookie時，將其屬性設為HttpOnly，就可以避免該網頁的cookie被客戶端惡意JavaScript竊取，保護使用者cookie資訊。
二、CSRF
CSRF(Cross Site Request Forgery)，即跨站請求偽造，是一種常見的Web攻擊，它利用使用者已登入的身份，在使用者毫不知情的情況下，以使用者的名義完成非法操作。
1.CSRF攻擊的原理
下面先介紹一下CSRF攻擊的原理：
完成 CSRF 攻擊必須要有三個條件：
- 使用者已經登入了站點 A，並在本地記錄了 cookie
- 在使用者沒有登出站點 A 的情況下（也就是 cookie 生效的情況下），訪問了惡意攻擊者提供的引誘危險站點 B (B 站點要求訪問站點A)。
- 站點 A 沒有做任何 CSRF 防禦
我們來看一個例子： 當我們登入轉賬頁面後，突然眼前一亮驚現”XXX隱私照片，不看後悔一輩子”的連結，耐不住內心躁動，立馬點選了該危險的網站（頁面程式碼如下圖所示），但當這頁面一載入，便會執行submitForm這個方法來提交轉賬請求，從而將10塊轉給黑客。
2.如何防禦
防範 CSRF 攻擊可以遵循以下幾種規則：
- Get 請求不對資料進行修改
- 不讓第三方網站訪問到使用者 Cookie
- 阻止第三方網站請求介面
- 請求時附帶驗證資訊，比如驗證碼或者 Token
1) SameSite
可以對 Cookie 設定 SameSite 屬性。該屬性表示 Cookie 不隨著跨域請求傳送，可以很大程度減少 CSRF 的攻擊，但是該屬性目前並不是所有瀏覽器都相容。
2) Referer Check
HTTP Referer是header的一部分，當瀏覽器向web伺服器傳送請求時，一般會帶上Referer資訊告訴伺服器是從哪個頁面連結過來的，伺服器籍此可以獲得一些資訊用於處理。可以通過檢查請求的來源來防禦CSRF攻擊。正常請求的referer具有一定規律，如在提交表單的referer必定是在該頁面發起的請求。所以通過檢查http包頭referer的值是不是這個頁面，來判斷是不是CSRF攻擊。
但在某些情況下如從https跳轉到http，瀏覽器處於安全考慮，不會傳送referer，伺服器就無法進行check了。若與該網站同域的其他網站有XSS漏洞，那麼攻擊者可以在其他網站注入惡意指令碼，受害者進入了此類同域的網址，也會遭受攻擊。出於以上原因，無法完全依賴Referer Check作為防禦CSRF的主要手段。但是可以通過Referer Check來監控CSRF攻擊的發生。
3) Anti CSRF Token
目前比較完善的解決方案是加入Anti-CSRF-Token。即傳送請求時在HTTP 請求中以引數的形式加入一個隨機產生的token，並在伺服器建立一個攔截器來驗證這個token。伺服器讀取瀏覽器當前域cookie中這個token值，會進行校驗該請求當中的token和cookie當中的token值是否都存在且相等，才認為這是合法的請求。否則認為這次請求是違法的，拒絕該次服務。
這種方法相比Referer檢查要安全很多，token可以在使用者登陸後產生並放於session或cookie中，然後在每次請求時伺服器把token從session或cookie中拿出，與本次請求中的token 進行比對。由於token的存在，攻擊者無法再構造出一個完整的URL實施CSRF攻擊。但在處理多個頁面共存問題時，當某個頁面消耗掉token後，其他頁面的表單儲存的還是被消耗掉的那個token，其他頁面的表單提交時會出現token錯誤。
4) 驗證碼
應用程式和使用者進行互動過程中，特別是賬戶交易這種核心步驟，強制使用者輸入驗證碼，才能完成最終請求。在通常情況下，驗證碼夠很好地遏制CSRF攻擊。但增加驗證碼降低了使用者的體驗，網站不能給所有的操作都加上驗證碼。所以只能將驗證碼作為一種輔助手段，在關鍵業務點設定驗證碼。
三、點選劫持
點選劫持是一種視覺欺騙的攻擊手段。攻擊者將需要攻擊的網站通過 iframe 巢狀的方式嵌入自己的網頁中，並將 iframe 設定為透明，在頁面中透出一個按鈕誘導使用者點選。
1. 特點
- 隱蔽性較高，騙取使用者操作
- “UI-覆蓋攻擊”
- 利用iframe或者其它標籤的屬性
2. 點選劫持的原理
使用者在登陸 A 網站的系統後，被攻擊者誘惑開啟第三方網站，而第三方網站通過 iframe 引入了 A 網站的頁面內容，使用者在第三方網站中點選某個按鈕（被裝飾的按鈕），實際上是點選了 A 網站的按鈕。
接下來我們舉個例子：我在優酷釋出了很多視訊，想讓更多的人關注它，就可以通過點選劫持來實現
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
iframe { width: 1440px; height: 900px; position: absolute; top: -0px; left: -0px; z-index: 2; -moz-opacity: 0; opacity: 0; filter: alpha(opacity=0); } button { position: absolute; top: 270px; left: 1150px; z-index: 1; width: 90px; height:40px; } </style> ...... <button>點選脫衣</button> <img src="http://pic1.win4000.com/wallpaper/2018-03-19/5aaf2bf0122d2.jpg"> <iframe src="http://i.youku.com/u/UMjA0NTg4Njcy" scrolling="no"></iframe> |
從上圖可知，攻擊者通過圖片作為頁面背景，隱藏了使用者操作的真實介面，當你按耐不住好奇點選按鈕以後，真正的點選的其實是隱藏的那個頁面的訂閱按鈕，然後就會在你不知情的情況下訂閱了。
3. 如何防禦
1）X-FRAME-OPTIONS
X-FRAME-OPTIONS是一個 HTTP 響應頭，在現代瀏覽器有一個很好的支援。這個 HTTP 響應頭 就是為了防禦用 iframe 巢狀的點選劫持攻擊。
該響應頭有三個值可選，分別是
- DENY，表示頁面不允許通過 iframe 的方式展示
- SAMEORIGIN，表示頁面可以在相同域名下通過 iframe 的方式展示
- ALLOW-FROM，表示頁面可以在指定來源的 iframe 中展示
2）JavaScript 防禦
對於某些遠古瀏覽器來說，並不能支援上面的這種方式，那我們只有通過 JS 的方式來防禦點選劫持了。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<head> <style id="click-jack"> html { display: none !important; } </style> </head> <body> <script> if (self == top) { var style = document.getElementById('click-jack') document.body.removeChild(style) } else { top.location = self.location } </script> </body> |
以上程式碼的作用就是當通過 iframe 的方式載入頁面時，攻擊者的網頁直接不顯示所有內容了。
四、URL跳轉漏洞
定義：藉助未驗證的URL跳轉，將應用程式引導到不安全的第三方區域，從而導致的安全問題。
1.URL跳轉漏洞原理
黑客利用URL跳轉漏洞來誘導安全意識低的使用者點選，導致使用者資訊洩露或者資金的流失。其原理是黑客構建惡意連結(連結需要進行偽裝,儘可能迷惑),發在QQ群或者是瀏覽量多的貼吧/論壇中。
安全意識低的使用者點選後,經過伺服器或者瀏覽器解析後，跳到惡意的網站中。
惡意連結需要進行偽裝,經常的做法是熟悉的連結後面加上一個惡意的網址，這樣才迷惑使用者。
諸如偽裝成像如下的網址，你是否能夠識別出來是惡意網址呢？
|
1 2 3 4 |
http://gate.baidu.com/index?act=go&url=http://t.cn/RVTatrd http://qt.qq.com/safecheck.html?flag=1&url=http://t.cn/RVTatrd http://tieba.baidu.com/f/user/passport?jumpUrl=http://t.cn/RVTatrd |
2.實現方式：
- Header頭跳轉
- Javascript跳轉
- META標籤跳轉
這裡我們舉個Header頭跳轉實現方式：
|
1 2 3 4 |
<?php $url=$_GET['jumpto']; header("Location: $url"); ?> |
|
1 2 |
http://www.wooyun.org/login.php?jumpto=http://www.evil.com |
這裡使用者會認為www.wooyun.org都是可信的，但是點選上述連結將導致使用者最終訪問www.evil.com這個惡意網址。
3.如何防禦
1)referer的限制
如果確定傳遞URL引數進入的來源，我們可以通過該方式實現安全限制，保證該URL的有效性，避免惡意使用者自己生成跳轉連結
2)加入有效性驗證Token
我們保證所有生成的連結都是來自於我們可信域的，通過在生成的連結里加入使用者不可控的Token對生成的連結進行校驗，可以避免使用者生成自己的惡意連結從而被利用，但是如果功能本身要求比較開放，可能導致有一定的限制。
五、SQL隱碼攻擊
SQL隱碼攻擊是一種常見的Web安全漏洞，攻擊者利用這個漏洞，可以訪問或修改資料，或者利用潛在的資料庫漏洞進行攻擊。
1.SQL隱碼攻擊的原理
我們先舉一個萬能鑰匙的例子來說明其原理：
|
1 2 3 4 5 |
<form action="/login" method="POST"> <p>Username: <input type="text" name="username" /></p> <p>Password: <input type="password" name="password" /></p> <p><input type="submit" value="登陸" /></p> </form> |
後端的 SQL 語句可能是如下這樣的：
|
1 2 3 4 5 6 7 8 |
let querySQL = ` SELECT * FROM user WHERE username='${username}' AND psw='${password}' `; // 接下來就是執行 sql 語句... |
這是我們經常見到的登入頁面，但如果有一個惡意攻擊者輸入的使用者名稱是 admin' --，密碼隨意輸入，就可以直接登入系統了。why! —-這就是SQL隱碼攻擊
我們之前預想的SQL 語句是:
|
1 2 |
SELECT * FROM user WHERE username='admin' AND psw='password' |
但是惡意攻擊者用奇怪使用者名稱將你的 SQL 語句變成了如下形式：
|
1 2 |
SELECT * FROM user WHERE username='admin' --' AND psw='xxxx' |
在 SQL 中,' --是閉合和註釋的意思，– 是註釋後面的內容的意思，所以查詢語句就變成了：
|
1 2 |
SELECT * FROM user WHERE username='admin' |
所謂的萬能密碼,本質上就是SQL隱碼攻擊的一種利用方式。
一次SQL隱碼攻擊的過程包括以下幾個過程：
- 獲取使用者請求引數
- 拼接到程式碼當中
- SQL語句按照我們構造引數的語義執行成功
SQL隱碼攻擊的必備條件：
1.可以控制輸入的資料
2.伺服器要執行的程式碼拼接了控制的資料。
我們會發現SQL隱碼攻擊流程中與正常請求伺服器類似，只是黑客控制了資料，構造了SQL查詢，而正常的請求不會SQL查詢這一步，SQL隱碼攻擊的本質:資料和程式碼未分離，即資料當做了程式碼來執行。
2.危害
- 獲取資料庫資訊
- 管理員後臺使用者名稱和密碼
- 獲取其他資料庫敏感資訊：使用者名稱、密碼、手機號碼、身份證、銀行卡資訊……
- 整個資料庫：脫褲
- 獲取伺服器許可權
- 植入Webshell，獲取伺服器後門
- 讀取伺服器敏感檔案
3.如何防禦
- 嚴格限制Web應用的資料庫的操作許可權，給此使用者提供僅僅能夠滿足其工作的最低許可權，從而最大限度的減少注入攻擊對資料庫的危害
- 後端程式碼檢查輸入的資料是否符合預期，嚴格限制變數的型別，例如使用正規表示式進行一些匹配處理。
- 對進入資料庫的特殊字元（’，”，\，<，>，&，*，; 等）進行轉義處理，或編碼轉換。基本上所有的後端語言都有對字串進行轉義處理的方法，比如 lodash 的 lodash._escapehtmlchar 庫。
- 所有的查詢語句建議使用資料庫提供的引數化查詢介面，引數化的語句使用引數而不是將使用者輸入變數嵌入到 SQL 語句中，即不要直接拼接 SQL 語句。例如 Node.js 中的 mysqljs 庫的 query 方法中的 ? 佔位引數。
六、OS命令注入攻擊
OS命令注入和SQL隱碼攻擊差不多，只不過SQL隱碼攻擊是針對資料庫的，而OS命令注入是針對作業系統的。OS命令注入攻擊指通過Web應用，執行非法的作業系統命令達到攻擊的目的。只要在能呼叫Shell函式的地方就有存在被攻擊的風險。倘若呼叫Shell時存在疏漏，就可以執行插入的非法命令。
命令注入攻擊可以向Shell傳送命令，讓Windows或Linux作業系統的命令列啟動程式。也就是說，通過命令注入攻擊可執行作業系統上安裝著的各種程式。
1.原理
黑客構造命令提交給web應用程式，web應用程式提取黑客構造的命令，拼接到被執行的命令中，因黑客注入的命令打破了原有命令結構，導致web應用執行了額外的命令，最後web應用程式將執行的結果輸出到響應頁面中。
我們通過一個例子來說明其原理，假如需要實現一個需求：使用者提交一些內容到伺服器，然後在伺服器執行一些系統命令去返回一個結果給使用者
|
1 2 3 4 5 |
// 以 Node.js 為例，假如在介面中需要從 github 下載使用者指定的 repo const exec = require('mz/child_process').exec; let params = {/* 使用者輸入的引數 */}; exec(`git clone ${params.repo} /some/path`); |
如果 params.repo 傳入的是 https://github.com/admin/admin.github.io.git 確實能從指定的 git repo 上下載到想要的程式碼。
但是如果 params.repo 傳入的是 https://github.com/xx/xx.git && rm -rf /* && 恰好你的服務是用 root 許可權起的就糟糕了。
2.如何防禦
- 後端對前端提交內容進行規則限制（比如正規表示式）。
- 在呼叫系統命令前對所有傳入引數進行命令列引數轉義過濾。
- 不要直接拼接命令語句，藉助一些工具做拼接、轉義預處理，例如 Node.js 的
shell-escape npm包