在 Web 安全領(lǐng)域中，XSS 和 CSRF 是最常見(jiàn)的攻擊方式。本文將會(huì)簡(jiǎn)單介紹 XSS 和 CSRF 的攻防問(wèn)題。

1. xss

XSS，即 Cross Site Script，中譯是跨站腳本攻擊；其原本縮寫(xiě)是 CSS，但為了和層疊樣式表(Cascading Style Sheet)有所區(qū)分，因而在安全領(lǐng)域叫做 XSS。

XSS 攻擊是指攻擊者在網(wǎng)站上注入惡意的客戶(hù)端代碼，通過(guò)惡意腳本對(duì)客戶(hù)端網(wǎng)頁(yè)進(jìn)行篡改，從而在用戶(hù)瀏覽網(wǎng)頁(yè)時(shí)，對(duì)用戶(hù)瀏覽器進(jìn)行控制或者獲取用戶(hù)隱私數(shù)據(jù)的一種攻擊方式。

攻擊者對(duì)客戶(hù)端網(wǎng)頁(yè)注入的惡意腳本一般包括 JavaScript，有時(shí)也會(huì)包含 HTML 和 Flash。有很多種方式進(jìn)行 XSS 攻擊，但它們的共同點(diǎn)為：將一些隱私數(shù)據(jù)像 cookie、session 發(fā)送給攻擊者，將受害者重定向到一個(gè)由攻擊者控制的網(wǎng)站，在受害者的機(jī)器上進(jìn)行一些惡意操作。

XSS攻擊可以分為3類(lèi)：反射型（非持久型）、存儲(chǔ)型（持久型）、基于DOM。

1.1反射性

反射型 XSS 只是簡(jiǎn)單地把用戶(hù)輸入的數(shù)據(jù) “反射” 給瀏覽器，這種攻擊方式往往需要攻擊者誘使用戶(hù)點(diǎn)擊一個(gè)惡意鏈接，或者提交一個(gè)表單，或者進(jìn)入一個(gè)惡意網(wǎng)站時(shí)，注入腳本進(jìn)入被攻擊者的網(wǎng)站。

看一個(gè)示例。我先準(zhǔn)備一個(gè)如下的靜態(tài)頁(yè)：

惡意鏈接的地址指向了 localhost:8001/?q=111p=222。然后，我再啟一個(gè)簡(jiǎn)單的 Node 服務(wù)處理惡意鏈接的請(qǐng)求：

const http = require('http');
function handleReequest(req, res) {
  res.setHeader('Access-Control-Allow-Origin', '*');
  res.writeHead(200, {'Content-Type': 'text/html; charset=UTF-8'});
  res.write('script>alert("反射型 XSS 攻擊")/script>');
  res.end();
}
 
const server = new http.Server();
server.listen(8001, '127.0.0.1');
server.on('request', handleReequest);

當(dāng)用戶(hù)點(diǎn)擊惡意鏈接時(shí)，頁(yè)面跳轉(zhuǎn)到攻擊者預(yù)先準(zhǔn)備的頁(yè)面，會(huì)發(fā)現(xiàn)在攻擊者的頁(yè)面執(zhí)行了 js 腳本：

這樣就產(chǎn)生了反射型 XSS 攻擊。攻擊者可以注入任意的惡意腳本進(jìn)行攻擊，可能注入惡作劇腳本，或者注入能獲取用戶(hù)隱私數(shù)據(jù)(如cookie)的腳本，這取決于攻擊者的目的。

1.2存儲(chǔ)型

存儲(chǔ)型 XSS 會(huì)把用戶(hù)輸入的數(shù)據(jù) “存儲(chǔ)” 在服務(wù)器端，當(dāng)瀏覽器請(qǐng)求數(shù)據(jù)時(shí)，腳本從服務(wù)器上傳回并執(zhí)行。這種 XSS 攻擊具有很強(qiáng)的穩(wěn)定性。

比較常見(jiàn)的一個(gè)場(chǎng)景是攻擊者在社區(qū)或論壇上寫(xiě)下一篇包含惡意 JavaScript 代碼的文章或評(píng)論，文章或評(píng)論發(fā)表后，所有訪(fǎng)問(wèn)該文章或評(píng)論的用戶(hù)，都會(huì)在他們的瀏覽器中執(zhí)行這段惡意的 JavaScript 代碼。

舉一個(gè)示例。

先準(zhǔn)備一個(gè)輸入頁(yè)面：

input type="text" id="input">
button id="btn">Submit/button> 
script>
  const input = document.getElementById('input');
  const btn = document.getElementById('btn');
 
  let val;
  input.addEventListener('change', (e) => {
    val = e.target.value;
  },false);
  btn.addEventListener('click', (e) => {
    fetch('http://localhost:8001/save', {
      method: 'POST',
      body: val
    });
  }, false);
/script>

啟動(dòng)一個(gè) Node 服務(wù)監(jiān)聽(tīng) save 請(qǐng)求。為了簡(jiǎn)化，用一個(gè)變量來(lái)保存用戶(hù)的輸入：

const http = require('http');
let userInput = '';
 
function handleReequest(req, res) {
  const method = req.method;
  res.setHeader('Access-Control-Allow-Origin', '*');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type')
  if (method === 'POST'  req.url === '/save'){
    let body = '';
    req.on('data',chunk => {
      body += chunk;
    });
    req.on('end', () => {
      if (body) {
        userInput = body;
      }
      res.end();
    });
  } else {
    res.writeHead(200, {'Content-Type': 'text/html; charset=UTF-8'});
    res.write(userInput); //將輸入的腳本內(nèi)容返回給前端頁(yè)面
    res.end();
  }
}
 
const server = new http.Server();
server.listen(8001, '127.0.0.1');
server.on('request', handleReequest);

當(dāng)用戶(hù)點(diǎn)擊提交按鈕將輸入信息提交到服務(wù)端時(shí)，服務(wù)端通過(guò) userInput 變量保存了輸入內(nèi)容。當(dāng)用戶(hù)通過(guò) http://localhost:8001/${id} 訪(fǎng)問(wèn)時(shí)，服務(wù)端會(huì)返回與 id 對(duì)應(yīng)的內(nèi)容(本示例簡(jiǎn)化了處理)。如果用戶(hù)輸入了惡意腳本內(nèi)容，則其他用戶(hù)訪(fǎng)問(wèn)該內(nèi)容時(shí)，惡意腳本就會(huì)在瀏覽器端執(zhí)行：

1.3 基于DOM

基于 DOM 的 XSS 攻擊是指通過(guò)惡意腳本修改頁(yè)面的 DOM 結(jié)構(gòu)，是純粹發(fā)生在客戶(hù)端的攻擊。

看如下代碼：

h2>XSS: /h2>
input type="text" id="input">
button id="btn">Submit/button>
div id="div">/div>
script>
  const input = document.getElementById('input');
  const btn = document.getElementById('btn');
  const div = document.getElementById('div');
  let val;
  input.addEventListener('change', (e) => {
    val = e.target.value;
  }, false);
  btn.addEventListener('click', () => {
    div.innerHTML = `a href=${val}>testLink/a>`
  }, false);
/script>

點(diǎn)擊 Submit 按鈕后，會(huì)在當(dāng)前頁(yè)面插入一個(gè)鏈接，其地址為用戶(hù)的輸入內(nèi)容。如果用戶(hù)在輸入時(shí)構(gòu)造了如下內(nèi)容：

'' onclick=alert(/xss/)

用戶(hù)提交之后，頁(yè)面代碼就變成了：

a href onlick="alert(/xss/)">testLink/a>

此時(shí)，用戶(hù)點(diǎn)擊生成的鏈接，就會(huì)執(zhí)行對(duì)應(yīng)的腳本：

2.XSS攻擊的防范

現(xiàn)在主流的瀏覽器內(nèi)置了防范 XSS 的措施，例如 CSP。但對(duì)于開(kāi)發(fā)者來(lái)說(shuō)，也應(yīng)該尋找可靠的解決方案來(lái)防止 XSS 攻擊。

2.1 HttpOnly 防止劫取 Cookie

HttpOnly 最早由微軟提出，至今已經(jīng)成為一個(gè)標(biāo)準(zhǔn)。瀏覽器將禁止頁(yè)面的Javascript 訪(fǎng)問(wèn)帶有 HttpOnly 屬性的Cookie。

上文有說(shuō)到，攻擊者可以通過(guò)注入惡意腳本獲取用戶(hù)的 Cookie 信息。通常 Cookie 中都包含了用戶(hù)的登錄憑證信息，攻擊者在獲取到 Cookie 之后，則可以發(fā)起 Cookie 劫持攻擊。所以，嚴(yán)格來(lái)說(shuō)，HttpOnly 并非阻止 XSS 攻擊，而是能阻止 XSS 攻擊后的 Cookie 劫持攻擊。

2.2 輸入檢查

不要相信用戶(hù)的任何輸入。 對(duì)于用戶(hù)的任何輸入要進(jìn)行檢查、過(guò)濾和轉(zhuǎn)義。建立可信任的字符和 HTML 標(biāo)簽白名單，對(duì)于不在白名單之列的字符或者標(biāo)簽進(jìn)行過(guò)濾或編碼。

在 XSS 防御中，輸入檢查一般是檢查用戶(hù)輸入的數(shù)據(jù)中是否包含 ，> 等特殊字符，如果存在，則對(duì)特殊字符進(jìn)行過(guò)濾或編碼，這種方式也稱(chēng)為 XSS Filter。

而在一些前端框架中，都會(huì)有一份 decodingMap， 用于對(duì)用戶(hù)輸入所包含的特殊字符或標(biāo)簽進(jìn)行編碼或過(guò)濾，如 ，>，script，防止 XSS 攻擊：

// vuejs 中的 decodingMap
// 在 vuejs 中，如果輸入帶 script 標(biāo)簽的內(nèi)容，會(huì)直接過(guò)濾掉
const decodingMap = {
 '': '',
 '>': '>',
 '"': '"',
 '': '',
 '
 ': '\n'
}

2.3輸出檢查

用戶(hù)的輸入會(huì)存在問(wèn)題，服務(wù)端的輸出也會(huì)存在問(wèn)題。一般來(lái)說(shuō)，除富文本的輸出外，在變量輸出到 HTML 頁(yè)面時(shí)，可以使用編碼或轉(zhuǎn)義的方式來(lái)防御 XSS 攻擊。例如利用 sanitize-html 對(duì)輸出內(nèi)容進(jìn)行有規(guī)則的過(guò)濾之后再輸出到頁(yè)面中。

3.CSRF

CSRF，即 Cross Site Request Forgery，中譯是跨站請(qǐng)求偽造，是一種劫持受信任用戶(hù)向服務(wù)器發(fā)送非預(yù)期請(qǐng)求的攻擊方式。

通常情況下，CSRF 攻擊是攻擊者借助受害者的 Cookie 騙取服務(wù)器的信任，可以在受害者毫不知情的情況下以受害者名義偽造請(qǐng)求發(fā)送給受攻擊服務(wù)器，從而在并未授權(quán)的情況下執(zhí)行在權(quán)限保護(hù)之下的操作。

在舉例子之前，先說(shuō)說(shuō)瀏覽器的 Cookie 策略

3.1 瀏覽器的 Cookie 策略

Cookie 是服務(wù)器發(fā)送到用戶(hù)瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會(huì)在瀏覽器下次向同一服務(wù)器再發(fā)起請(qǐng)求時(shí)被攜帶并發(fā)送到服務(wù)器上。Cookie 主要用于以下三個(gè)方面：

• 會(huì)話(huà)狀態(tài)管理（如用戶(hù)登錄狀態(tài)、購(gòu)物車(chē)、游戲分?jǐn)?shù)或其它需要記錄的信息）
• 個(gè)性化設(shè)置（如用戶(hù)自定義設(shè)置、主題等）
• 個(gè)性化設(shè)置（如用戶(hù)自定義設(shè)置、主題等）

而瀏覽器所持有的 Cookie 分為兩種：

• Session Cookie(會(huì)話(huà)期 Cookie)：會(huì)話(huà)期 Cookie 是最簡(jiǎn)單的Cookie，它不需要指定過(guò)期時(shí)間（Expires）或者有效期（Max-Age），它僅在會(huì)話(huà)期內(nèi)有效，瀏覽器關(guān)閉之后它會(huì)被自動(dòng)刪除。
• Permanent Cookie(持久性 Cookie)：與會(huì)話(huà)期 Cookie 不同的是，持久性 Cookie 可以指定一個(gè)特定的過(guò)期時(shí)間（Expires）或有效期（Max-Age）。

res.setHeader('Set-Cookie', ['mycookie=222', 'test=3333; expires=Sat, 21 Jul 2018 00:00:00 GMT;']);

上述代碼創(chuàng)建了兩個(gè) Cookie：mycookie 和 test，前者屬于會(huì)話(huà)期 Cookie，后者則屬于持久性 Cookie。當(dāng)我們?nèi)ゲ榭?Cookie 相關(guān)的屬性時(shí)，不同的瀏覽器對(duì)會(huì)話(huà)期 Cookie 的 Expires 屬性值會(huì)不一樣：

此外，每個(gè) Cookie 都會(huì)有與之關(guān)聯(lián)的域，這個(gè)域的范圍一般通過(guò) donmain 屬性指定。如果 Cookie 的域和頁(yè)面的域相同，那么我們稱(chēng)這個(gè) Cookie 為第一方 Cookie（first-party cookie），如果 Cookie 的域和頁(yè)面的域不同，則稱(chēng)之為第三方 Cookie（third-party cookie）。一個(gè)頁(yè)面包含圖片或存放在其他域上的資源（如圖片）時(shí)，第一方的 Cookie 也只會(huì)發(fā)送給設(shè)置它們的服務(wù)器。

3.2 通過(guò) Cookie 進(jìn)行 CSRF 攻擊

假設(shè)有一個(gè) bbs 站點(diǎn)：http://www.c.com，當(dāng)?shù)卿浐蟮挠脩?hù)發(fā)起如下 GET 請(qǐng)求時(shí)，會(huì)刪除 ID 指定的帖子：

http://www.c.com:8002/content/delete/:id

如發(fā)起 http://www.c.com:8002/content/delete/87343 請(qǐng)求時(shí)，會(huì)刪除 id 為 87343 的帖子。當(dāng)用戶(hù)登錄之后，會(huì)設(shè)置如下 cookie：

res.setHeader('Set-Cookie', ['user=22333; expires=Sat, 21 Jul 2018 00:00:00 GMT;']);

user 對(duì)應(yīng)的值是用戶(hù) ID。然后構(gòu)造一個(gè)頁(yè)面 A：

CSRF 攻擊者準(zhǔn)備的網(wǎng)站：

p>CSRF 攻擊者準(zhǔn)備的網(wǎng)站：/p>
img src="http://www.c.com:8002/content/delete/87343">

頁(yè)面 A 使用了一個(gè) img 標(biāo)簽，其地址指向了刪除用戶(hù)帖子的鏈接：

可以看到，當(dāng)?shù)卿浻脩?hù)訪(fǎng)問(wèn)攻擊者的網(wǎng)站時(shí)，會(huì)向 www.c.com 發(fā)起一個(gè)刪除用戶(hù)帖子的請(qǐng)求。此時(shí)若用戶(hù)在切換到 www.c.com 的帖子頁(yè)面刷新，會(huì)發(fā)現(xiàn)ID 為 87343 的帖子已經(jīng)被刪除。

由于 Cookie 中包含了用戶(hù)的認(rèn)證信息，當(dāng)用戶(hù)訪(fǎng)問(wèn)攻擊者準(zhǔn)備的攻擊環(huán)境時(shí)，攻擊者就可以對(duì)服務(wù)器發(fā)起 CSRF 攻擊。在這個(gè)攻擊過(guò)程中，攻擊者借助受害者的 Cookie 騙取服務(wù)器的信任，但并不能拿到 Cookie，也看不到 Cookie 的內(nèi)容。而對(duì)于服務(wù)器返回的結(jié)果，由于瀏覽器同源策略的限制，攻擊者也無(wú)法進(jìn)行解析。因此，攻擊者無(wú)法從返回的結(jié)果中得到任何東西，他所能做的就是給服務(wù)器發(fā)送請(qǐng)求，以執(zhí)行請(qǐng)求中所描述的命令，在服務(wù)器端直接改變數(shù)據(jù)的值，而非竊取服務(wù)器中的數(shù)據(jù)。

但若 CSRF 攻擊的目標(biāo)并不需要使用 Cookie，則也不必顧慮瀏覽器的 Cookie 策略了。

4.CSRF 攻擊的防范

當(dāng)前，對(duì) CSRF 攻擊的防范措施主要有如下幾種方式。

4.1 驗(yàn)證碼

驗(yàn)證碼被認(rèn)為是對(duì)抗 CSRF 攻擊最簡(jiǎn)潔而有效的防御方法。

從上述示例中可以看出，CSRF 攻擊往往是在用戶(hù)不知情的情況下構(gòu)造了網(wǎng)絡(luò)請(qǐng)求。而驗(yàn)證碼會(huì)強(qiáng)制用戶(hù)必須與應(yīng)用進(jìn)行交互，才能完成最終請(qǐng)求。因?yàn)橥ǔＧ闆r下，驗(yàn)證碼能夠很好地遏制 CSRF 攻擊。

但驗(yàn)證碼并不是萬(wàn)能的，因?yàn)槌鲇谟脩?hù)考慮，不能給網(wǎng)站所有的操作都加上驗(yàn)證碼。因此，驗(yàn)證碼只能作為防御 CSRF 的一種輔助手段，而不能作為最主要的解決方案。

4.2 Referer Check

根據(jù) HTTP 協(xié)議，在 HTTP 頭中有一個(gè)字段叫 Referer，它記錄了該 HTTP 請(qǐng)求的來(lái)源地址。通過(guò) Referer Check，可以檢查請(qǐng)求是否來(lái)自合法的”源”。

比如，如果用戶(hù)要?jiǎng)h除自己的帖子，那么先要登錄 www.c.com，然后找到對(duì)應(yīng)的頁(yè)面，發(fā)起刪除帖子的請(qǐng)求。此時(shí)，Referer 的值是 http://www.c.com；當(dāng)請(qǐng)求是從 www.a.com 發(fā)起時(shí)，Referer 的值是 http://www.a.com 了。因此，要防御 CSRF 攻擊，只需要對(duì)于每一個(gè)刪帖請(qǐng)求驗(yàn)證其 Referer 值，如果是以 www.c.com 開(kāi)頭的域名，則說(shuō)明該請(qǐng)求是來(lái)自網(wǎng)站自己的請(qǐng)求，是合法的。如果 Referer 是其他網(wǎng)站的話(huà)，則有可能是 CSRF 攻擊，可以拒絕該請(qǐng)求。

針對(duì)上文的例子，可以在服務(wù)端增加如下代碼：

if (req.headers.referer !== 'http://www.c.com:8002/') {
  res.write('csrf 攻擊');
  return;
}

Referer Check 不僅能防范 CSRF 攻擊，另一個(gè)應(yīng)用場(chǎng)景是 “防止圖片盜鏈”。

4.3 添加 token 驗(yàn)證(token==令牌)

CSRF 攻擊之所以能夠成功，是因?yàn)楣粽呖梢酝耆珎卧煊脩?hù)的請(qǐng)求，該請(qǐng)求中所有的用戶(hù)驗(yàn)證信息都是存在于 Cookie 中，因此攻擊者可以在不知道這些驗(yàn)證信息的情況下直接利用用戶(hù)自己的 Cookie 來(lái)通過(guò)安全驗(yàn)證。要抵御 CSRF，關(guān)鍵在于在請(qǐng)求中放入攻擊者所不能偽造的信息，并且該信息不存在于 Cookie 之中?？梢栽?HTTP 請(qǐng)求中以參數(shù)的形式加入一個(gè)隨機(jī)產(chǎn)生的 token，并在服務(wù)器端建立一個(gè)攔截器來(lái)驗(yàn)證這個(gè) token，如果請(qǐng)求中沒(méi)有 token 或者 token 內(nèi)容不正確，則認(rèn)為可能是 CSRF 攻擊而拒絕該請(qǐng)求。

總結(jié)

本文主要介紹了 XSS 和 CSRF 的攻擊原理和防御措施。當(dāng)然，在 Web 安全領(lǐng)域，除了這兩種常見(jiàn)的攻擊方式，也存在這 SQL 注入等其它攻擊方式，這不在本文的討論范圍之內(nèi)，如果你對(duì)其感興趣，可以閱讀SQL注入技術(shù)專(zhuān)題的專(zhuān)欄詳細(xì)了解相關(guān)信息。最后，總結(jié)一下 XSS 攻擊和 CSRF 攻擊的常見(jiàn)防御措施：

1.防御XSS攻擊

• HttpOnly 防止劫取 Cookie
• 用戶(hù)的輸入檢查
• 服務(wù)端的輸出檢查

2.防御CSRF攻擊

• 驗(yàn)證碼
• Referer Check
• Token 驗(yàn)證

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。