常見六大Web安全攻防解析

前言

在互聯網時代，數據安全與個人隱私受到了前所未有的挑戰，各種新奇的攻擊技術層出不窮。如何才能更好地保護我們的數據？本文主要側重於分析幾種常見的攻擊的類型以及防禦的方法。

一、XSS

XSS (Cross-Site Scripting)，跨站腳本攻擊，因爲縮寫和 CSS重疊，所以只能叫 XSS。跨站腳本攻擊是指通過存在安全漏洞的Web網站註冊用戶的瀏覽器內運行非法的HTML標籤或JavaScript進行的一種攻擊。

跨站腳本攻擊有可能造成以下影響:

利用虛假輸入表單騙取用戶個人信息。
利用腳本竊取用戶的Cookie值，被害者在不知情的情況下，幫助攻擊者發送惡意請求。
顯示僞造的文章或圖片。

XSS 的原理是惡意攻擊者往 Web 頁面裏插入惡意可執行網頁腳本代碼，當用戶瀏覽該頁之時，嵌入其中 Web 裏面的腳本代碼會被執行，從而可以達到攻擊者盜取用戶信息或其他侵犯用戶安全隱私的目的。

XSS 的攻擊方式千變萬化，但還是可以大致細分爲幾種類型。

1.非持久型 XSS（反射型 XSS ）

非持久型 XSS 漏洞，一般是通過給別人發送帶有惡意腳本代碼參數的 URL，當 URL 地址被打開時，特有的惡意代碼參數被 HTML 解析、執行。

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

<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 來舉例：

只允許加載本站資源

Content-Security-Policy: default-src 'self'

只允許加載 HTTPS 協議圖片

Content-Security-Policy: img-src https://*

允許加載任何來源框架

Content-Security-Policy: child-src 'none'

如需瞭解更多屬性，請查看Content-Security-Policy文檔

對於這種方式來說，只要開發者配置了正確的規則，那麼即使網站存在漏洞，攻擊者也不能執行它的攻擊代碼，並且 CSP 的兼容性也不錯。

2) 轉義字符

用戶的輸入永遠不可信任的，最普遍的做法就是轉義輸入輸出的內容，對於引號、尖括號、斜槓進行轉義

function escape(str) {
  str = str.replace(/&/g, '&amp;')
  str = str.replace(/</g, '&lt;')
  str = str.replace(/>/g, '&gt;')
  str = str.replace(/"/g, '&quto;')
  str = str.replace(/'/g, '&#39;')
  str = str.replace(/`/g, '&#96;')
  str = str.replace(/\//g, '&#x2F;')
  return str
}

但是對於顯示富文本來說，顯然不能通過上面的辦法來轉義所有字符，因爲這樣會把需要的格式也過濾掉。對於這種情況，通常採用白名單過濾的辦法，當然也可以通過黑名單過濾，但是考慮到需要過濾的標籤和標籤屬性實在太多，更加推薦使用白名單的方式。

const xss = require('xss')
let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
// -> <h1>XSS Demo</h1>&lt;script&gt;alert("xss");&lt;/script&gt;
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 網站的按鈕。
接下來我們舉個例子：我在優酷發佈了很多視頻，想讓更多的人關注它，就可以通過點擊劫持來實現

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 的方式來防禦點擊劫持了。

<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羣或者是瀏覽量多的貼吧/論壇中。
安全意識低的用戶點擊後,經過服務器或者瀏覽器解析後，跳到惡意的網站中。

惡意鏈接需要進行僞裝,經常的做法是熟悉的鏈接後面加上一個惡意的網址，這樣才迷惑用戶。

諸如僞裝成像如下的網址，你是否能夠識別出來是惡意網址呢？

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頭跳轉實現方式：

<?php
$url=$_GET['jumpto'];
header("Location: $url");
?>

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注入的原理

我們先舉一個萬能鑰匙的例子來說明其原理：

<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 語句可能是如下這樣的：

let querySQL = `
    SELECT *
    FROM user
    WHERE username='${username}'
    AND psw='${password}'
`;
// 接下來就是執行 sql 語句...

這是我們經常見到的登錄頁面，但如果有一個惡意攻擊者輸入的用戶名是 admin' --，密碼隨意輸入，就可以直接登入系統了。why! ----這就是SQL注入

我們之前預想的SQL 語句是:

SELECT * FROM user WHERE username='admin' AND psw='password'

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

SELECT * FROM user WHERE username='admin' --' AND psw='xxxx'

在 SQL 中,' --是閉合和註釋的意思，-- 是註釋後面的內容的意思，所以查詢語句就變成了：

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應用程序將執行的結果輸出到響應頁面中。

我們通過一個例子來說明其原理，假如需要實現一個需求：用戶提交一些內容到服務器，然後在服務器執行一些系統命令去返回一個結果給用戶

// 以 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包