一、XSS

XSS，（ Cross Site Script，跨站腳本攻擊）其原本縮寫(xiě)是 CSS，但為了和層疊樣式表(Cascading Style Sheet)有所區(qū)分，因而在安全領(lǐng)域叫做 XSS。
XSS 攻擊是指攻擊者在網(wǎng)站上注入惡意的客戶端代碼，通過(guò)惡意腳本對(duì)客戶端網(wǎng)頁(yè)進(jìn)行篡改，從而在用戶瀏覽網(wǎng)頁(yè)時(shí)，對(duì)用戶瀏覽器進(jìn)行控制或者獲取用戶隱私數(shù)據(jù)的一種攻擊方式。攻擊者對(duì)客戶端網(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. 反射型
     反射型 XSS 只是簡(jiǎn)單地把用戶輸入的數(shù)據(jù) “反射” 給瀏覽器，這種攻擊方式往往需要攻擊者誘使用戶點(diǎn)擊一個(gè)惡意鏈接，或者提交一個(gè)表單，或者進(jìn)入一個(gè)惡意網(wǎng)站時(shí)，注入腳本進(jìn)入被攻擊者的網(wǎng)站。
• 2. 存儲(chǔ)型
     存儲(chǔ)型 XSS 會(huì)把用戶輸入的數(shù)據(jù) “存儲(chǔ)” 在服務(wù)器端，當(dāng)瀏覽器請(qǐng)求數(shù)據(jù)時(shí)，腳本從服務(wù)器上傳回并執(zhí)行。這種 XSS 攻擊具有很強(qiáng)的穩(wěn)定性。
     攻擊者在頁(yè)面中輸入以評(píng)論、文章等為形式惡意腳本并發(fā)送到服務(wù)端，當(dāng)其他用戶訪問(wèn)該評(píng)論或文章時(shí)，服務(wù)器會(huì)將這段惡意代碼返回，而其他用戶訪問(wèn)時(shí)，惡意腳本就會(huì)在瀏覽器執(zhí)行。
• 3.基于DOM
  基于 DOM 的 XSS 攻擊是指通過(guò)惡意腳本修改頁(yè)面的 DOM 結(jié)構(gòu)，是純粹發(fā)生在客戶端的攻擊。

<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è)鏈接，其地址為用戶的輸入內(nèi)容。如果用戶在輸入時(shí)構(gòu)造了如下內(nèi)容，但如果攻擊者在輸入框中輸入內(nèi)容 onclick=alert(/xss/)，提交后頁(yè)面中的 a 鏈接就變成了 <a href onlick="alert(/xss/)">testLink</a> 此時(shí)，用戶點(diǎn)擊生成的鏈接，就會(huì)執(zhí)行對(duì)應(yīng)的腳本

• 防范
  現(xiàn)在主流的瀏覽器內(nèi)置了防范 XSS 的措施，例如 CSP。但對(duì)于開(kāi)發(fā)者來(lái)說(shuō)，也應(yīng)該尋找可靠的解決方案來(lái)防止 XSS 攻擊。
• 1.HttpOnly 防止劫取 Cookie
  HttpOnly 最早由微軟提出，至今已經(jīng)成為一個(gè)標(biāo)準(zhǔn)。瀏覽器將禁止頁(yè)面的Javascript 訪問(wèn)帶有 HttpOnly 屬性的Cookie。
  上文有說(shuō)到，攻擊者可以通過(guò)注入惡意腳本獲取用戶的 Cookie 信息。通常 Cookie 中都包含了用戶的登錄憑證信息，攻擊者在獲取到 Cookie 之后，則可以發(fā)起 Cookie 劫持攻擊。所以，嚴(yán)格來(lái)說(shuō)，HttpOnly 并非阻止 XSS 攻擊，而是能阻止 XSS 攻擊后的 Cookie 劫持攻擊。
• 2.輸入檢查
  不要相信用戶的任何輸入。 對(duì)于用戶的任何輸入要進(jìn)行檢查、過(guò)濾和轉(zhuǎn)義。建立可信任的字符和 HTML 標(biāo)簽白名單，對(duì)于不在白名單之列的字符或者標(biāo)簽進(jìn)行過(guò)濾或編碼。
  在 XSS 防御中，輸入檢查一般是檢查用戶輸入的數(shù)據(jù)中是否包含 <，> 等特殊字符，如果存在，則對(duì)特殊字符進(jìn)行過(guò)濾或編碼，這種方式也稱為 XSS Filter。而在一些前端框架中，都會(huì)有一份 decodingMap， 用于對(duì)用戶輸入所包含的特殊字符或標(biāo)簽進(jìn)行編碼或過(guò)濾，如 <，>，script，防止 XSS 攻擊
• 3.輸出檢查
  用戶的輸入會(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è)面中。

二、CSRF

CSRF，（Cross Site Request Forgery，跨站請(qǐng)求偽造）是一種劫持受信任用戶向服務(wù)器發(fā)送非預(yù)期請(qǐng)求的攻擊方式。
通常情況下，CSRF 攻擊是攻擊者借助受害者的 Cookie 騙取服務(wù)器的信任，可以在受害者毫不知情的情況下以受害者名義偽造請(qǐng)求發(fā)送給受攻擊服務(wù)器，從而在并未授權(quán)的情況下執(zhí)行在權(quán)限保護(hù)之下的操作。
先說(shuō)說(shuō)瀏覽器的 Cookie 策略
Cookie 是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會(huì)在瀏覽器下次向同一服務(wù)器再發(fā)起請(qǐng)求時(shí)被攜帶并發(fā)送到服務(wù)器上。Cookie 主要用于以下三個(gè)方面：

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

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

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

此外，每個(gè) Cookie 都會(huì)有與之關(guān)聯(lián)的域，這個(gè)域的范圍一般通過(guò) donmain 屬性指定。如果 Cookie 的域和頁(yè)面的域相同，那么我們稱這個(gè) Cookie 為第一方 Cookie（first-party cookie），如果 Cookie 的域和頁(yè)面的域不同，則稱之為第三方 Cookie（third-party cookie）。一個(gè)頁(yè)面包含圖片或存放在其他域上的資源（如圖片）時(shí)，第一方的 Cookie 也只會(huì)發(fā)送給設(shè)置它們的服務(wù)器。
由于 Cookie 中包含了用戶的認(rèn)證信息，當(dā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 策略了。

• 防范
• 1.驗(yàn)證碼
  驗(yàn)證碼被認(rèn)為是對(duì)抗 CSRF 攻擊最簡(jiǎn)潔而有效的防御方法。
  從上述示例中可以看出，CSRF 攻擊往往是在用戶不知情的情況下構(gòu)造了網(wǎng)絡(luò)請(qǐng)求。而驗(yàn)證碼會(huì)強(qiáng)制用戶必須與應(yīng)用進(jìn)行交互，才能完成最終請(qǐng)求。因?yàn)橥ǔＧ闆r下，驗(yàn)證碼能夠很好地遏制 CSRF 攻擊。
  但驗(yàn)證碼并不是萬(wàn)能的，因?yàn)槌鲇谟脩艨紤]，不能給網(wǎng)站所有的操作都加上驗(yàn)證碼。因此，驗(yàn)證碼只能作為防御 CSRF 的一種輔助手段，而不能作為最主要的解決方案。
• 2.Referer Check
  根據(jù) HTTP 協(xié)議，在 HTTP 頭中有一個(gè)字段叫 Referer，它記錄了該 HTTP 請(qǐng)求的來(lái)源地址。通過(guò) Referer Check，可以檢查請(qǐng)求是否來(lái)自合法的”源”。
  比如，如果用戶要?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)站的話，則有可能是 CSRF 攻擊，可以拒絕該請(qǐng)求。
  Referer Check 不僅能防范 CSRF 攻擊，另一個(gè)應(yīng)用場(chǎng)景是 “防止圖片盜鏈”。
• 3.添加 token 驗(yàn)證
  CSRF 攻擊之所以能夠成功，是因?yàn)楣粽呖梢酝耆珎卧煊脩舻恼?qǐng)求，該請(qǐng)求中所有的用戶驗(yàn)證信息都是存在于 Cookie 中，因此攻擊者可以在不知道這些驗(yàn)證信息的情況下直接利用用戶自己的 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)求。