一搔谴、XSS
XSS魁袜，（ Cross Site Script，跨站腳本攻擊）其原本縮寫是 CSS己沛，但為了和層疊樣式表(Cascading Style Sheet)有所區(qū)分慌核，因而在安全領(lǐng)域叫做 XSS。
XSS 攻擊是指攻擊者在網(wǎng)站上注入惡意的客戶端代碼申尼，通過惡意腳本對客戶端網(wǎng)頁進(jìn)行篡改垮卓，從而在用戶瀏覽網(wǎng)頁時(shí)，對用戶瀏覽器進(jìn)行控制或者獲取用戶隱私數(shù)據(jù)的一種攻擊方式师幕。攻擊者對客戶端網(wǎng)頁注入的惡意腳本一般包括 JavaScript粟按，有時(shí)也會(huì)包含 HTML 和 Flash。有很多種方式進(jìn)行 XSS 攻擊霹粥，但它們的共同點(diǎn)為：將一些隱私數(shù)據(jù)像 cookie灭将、session 發(fā)送給攻擊者，將受害者重定向到一個(gè)由攻擊者控制的網(wǎng)站后控，在受害者的機(jī)器上進(jìn)行一些惡意操作庙曙。
XSS攻擊可以分為3類：反射型（非持久型）、存儲(chǔ)型（持久型）浩淘、基于DOM捌朴。
- 反射型
反射型 XSS 只是簡單地把用戶輸入的數(shù)據(jù) “反射” 給瀏覽器，這種攻擊方式往往需要攻擊者誘使用戶點(diǎn)擊一個(gè)惡意鏈接张抄，或者提交一個(gè)表單砂蔽，或者進(jìn)入一個(gè)惡意網(wǎng)站時(shí)，注入腳本進(jìn)入被攻擊者的網(wǎng)站署惯。
- 反射型
- 存儲(chǔ)型
存儲(chǔ)型 XSS 會(huì)把用戶輸入的數(shù)據(jù) “存儲(chǔ)” 在服務(wù)器端左驾，當(dāng)瀏覽器請求數(shù)據(jù)時(shí)，腳本從服務(wù)器上傳回并執(zhí)行。這種 XSS 攻擊具有很強(qiáng)的穩(wěn)定性诡右。
攻擊者在頁面中輸入以評論安岂、文章等為形式惡意腳本并發(fā)送到服務(wù)端，當(dāng)其他用戶訪問該評論或文章時(shí)稻爬，服務(wù)器會(huì)將這段惡意代碼返回嗜闻，而其他用戶訪問時(shí)，惡意腳本就會(huì)在瀏覽器執(zhí)行桅锄。
- 存儲(chǔ)型
- 3.基于DOM
基于 DOM 的 XSS 攻擊是指通過惡意腳本修改頁面的 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)前頁面插入一個(gè)鏈接翠肘，其地址為用戶的輸入內(nèi)容。如果用戶在輸入時(shí)構(gòu)造了如下內(nèi)容辫秧，但如果攻擊者在輸入框中輸入內(nèi)容 onclick=alert(/xss/)束倍，提交后頁面中的 a 鏈接就變成了 <a href onlick="alert(/xss/)">testLink</a> 此時(shí)，用戶點(diǎn)擊生成的鏈接盟戏，就會(huì)執(zhí)行對應(yīng)的腳本
- 防范
現(xiàn)在主流的瀏覽器內(nèi)置了防范 XSS 的措施绪妹，例如 CSP。但對于開發(fā)者來說柿究，也應(yīng)該尋找可靠的解決方案來防止 XSS 攻擊邮旷。 - 1.HttpOnly 防止劫取 Cookie
HttpOnly 最早由微軟提出，至今已經(jīng)成為一個(gè)標(biāo)準(zhǔn)蝇摸。瀏覽器將禁止頁面的Javascript 訪問帶有 HttpOnly 屬性的Cookie婶肩。
上文有說到，攻擊者可以通過注入惡意腳本獲取用戶的 Cookie 信息貌夕。通常 Cookie 中都包含了用戶的登錄憑證信息律歼，攻擊者在獲取到 Cookie 之后，則可以發(fā)起 Cookie 劫持攻擊啡专。所以险毁，嚴(yán)格來說，HttpOnly 并非阻止 XSS 攻擊们童，而是能阻止 XSS 攻擊后的 Cookie 劫持攻擊辱揭。 - 2.輸入檢查
不要相信用戶的任何輸入。 對于用戶的任何輸入要進(jìn)行檢查病附、過濾和轉(zhuǎn)義。建立可信任的字符和 HTML 標(biāo)簽白名單亥鬓，對于不在白名單之列的字符或者標(biāo)簽進(jìn)行過濾或編碼完沪。
在 XSS 防御中，輸入檢查一般是檢查用戶輸入的數(shù)據(jù)中是否包含 <，> 等特殊字符覆积，如果存在听皿，則對特殊字符進(jìn)行過濾或編碼，這種方式也稱為 XSS Filter宽档。而在一些前端框架中尉姨，都會(huì)有一份 decodingMap， 用于對用戶輸入所包含的特殊字符或標(biāo)簽進(jìn)行編碼或過濾吗冤，如 <又厉，>，script椎瘟，防止 XSS 攻擊 - 3.輸出檢查
用戶的輸入會(huì)存在問題覆致，服務(wù)端的輸出也會(huì)存在問題。一般來說肺蔚，除富文本的輸出外煌妈，在變量輸出到 HTML 頁面時(shí)，可以使用編碼或轉(zhuǎn)義的方式來防御 XSS 攻擊宣羊。例如利用 sanitize-html 對輸出內(nèi)容進(jìn)行有規(guī)則的過濾之后再輸出到頁面中璧诵。
二、CSRF
CSRF仇冯，（Cross Site Request Forgery之宿，跨站請求偽造）是一種劫持受信任用戶向服務(wù)器發(fā)送非預(yù)期請求的攻擊方式。
通常情況下赞枕，CSRF 攻擊是攻擊者借助受害者的 Cookie 騙取服務(wù)器的信任澈缺，可以在受害者毫不知情的情況下以受害者名義偽造請求發(fā)送給受攻擊服務(wù)器，從而在并未授權(quán)的情況下執(zhí)行在權(quán)限保護(hù)之下的操作炕婶。
先說說瀏覽器的 Cookie 策略
Cookie 是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)姐赡，它會(huì)在瀏覽器下次向同一服務(wù)器再發(fā)起請求時(shí)被攜帶并發(fā)送到服務(wù)器上。Cookie 主要用于以下三個(gè)方面：
- 會(huì)話狀態(tài)管理（如用戶登錄狀態(tài)柠掂、購物車项滑、游戲分?jǐn)?shù)或其它需要記錄的信息）
- 個(gè)性化設(shè)置（如用戶自定義設(shè)置、主題等）
- 個(gè)性化設(shè)置（如用戶自定義設(shè)置涯贞、主題等）
而瀏覽器所持有的 Cookie 分為兩種：
- Session Cookie(會(huì)話期 Cookie)：會(huì)話期 Cookie 是最簡單的Cookie枪狂，它不需要指定過期時(shí)間（Expires）或者有效期（Max-Age），它僅在會(huì)話期內(nèi)有效宋渔，瀏覽器關(guān)閉之后它會(huì)被自動(dòng)刪除州疾。
- Permanent Cookie(持久性 Cookie)：與會(huì)話期 Cookie 不同的是，持久性 Cookie 可以指定一個(gè)特定的過期時(shí)間（Expires）或有效期（Max-Age）皇拣。
此外严蓖，每個(gè) Cookie 都會(huì)有與之關(guān)聯(lián)的域薄嫡，這個(gè)域的范圍一般通過 donmain 屬性指定。如果 Cookie 的域和頁面的域相同颗胡，那么我們稱這個(gè) Cookie 為第一方 Cookie（first-party cookie）毫深，如果 Cookie 的域和頁面的域不同，則稱之為第三方 Cookie（third-party cookie）毒姨。一個(gè)頁面包含圖片或存放在其他域上的資源（如圖片）時(shí)哑蔫，第一方的 Cookie 也只會(huì)發(fā)送給設(shè)置它們的服務(wù)器。
由于 Cookie 中包含了用戶的認(rèn)證信息弧呐，當(dāng)用戶訪問攻擊者準(zhǔn)備的攻擊環(huán)境時(shí)闸迷，攻擊者就可以對服務(wù)器發(fā)起 CSRF 攻擊。在這個(gè)攻擊過程中泉懦，攻擊者借助受害者的 Cookie 騙取服務(wù)器的信任稿黍，但并不能拿到 Cookie，也看不到 Cookie 的內(nèi)容崩哩。而對于服務(wù)器返回的結(jié)果巡球，由于瀏覽器同源策略的限制，攻擊者也無法進(jìn)行解析邓嘹。因此酣栈，攻擊者無法從返回的結(jié)果中得到任何東西，他所能做的就是給服務(wù)器發(fā)送請求汹押，以執(zhí)行請求中所描述的命令矿筝，在服務(wù)器端直接改變數(shù)據(jù)的值，而非竊取服務(wù)器中的數(shù)據(jù)棚贾。但若 CSRF 攻擊的目標(biāo)并不需要使用 Cookie窖维，則也不必顧慮瀏覽器的 Cookie 策略了。
- 防范
- 1.驗(yàn)證碼
驗(yàn)證碼被認(rèn)為是對抗 CSRF 攻擊最簡潔而有效的防御方法妙痹。
從上述示例中可以看出铸史，CSRF 攻擊往往是在用戶不知情的情況下構(gòu)造了網(wǎng)絡(luò)請求。而驗(yàn)證碼會(huì)強(qiáng)制用戶必須與應(yīng)用進(jìn)行交互怯伊，才能完成最終請求琳轿。因?yàn)橥ǔＧ闆r下，驗(yàn)證碼能夠很好地遏制 CSRF 攻擊耿芹。
但驗(yàn)證碼并不是萬能的崭篡，因?yàn)槌鲇谟脩艨紤]，不能給網(wǎng)站所有的操作都加上驗(yàn)證碼吧秕。因此琉闪，驗(yàn)證碼只能作為防御 CSRF 的一種輔助手段，而不能作為最主要的解決方案砸彬。 - 2.Referer Check
根據(jù) HTTP 協(xié)議塘偎，在 HTTP 頭中有一個(gè)字段叫 Referer疗涉，它記錄了該 HTTP 請求的來源地址。通過 Referer Check吟秩，可以檢查請求是否來自合法的”源”。
比如绽淘，如果用戶要?jiǎng)h除自己的帖子涵防，那么先要登錄 www.c.com，然后找到對應(yīng)的頁面沪铭，發(fā)起刪除帖子的請求壮池。此時(shí)，Referer 的值是 http://www.c.com杀怠；當(dāng)請求是從 www.a.com 發(fā)起時(shí)椰憋，Referer 的值是 http://www.a.com 了。因此赔退，要防御 CSRF 攻擊橙依，只需要對于每一個(gè)刪帖請求驗(yàn)證其 Referer 值，如果是以 www.c.com 開頭的域名硕旗，則說明該請求是來自網(wǎng)站自己的請求窗骑，是合法的。如果 Referer 是其他網(wǎng)站的話漆枚，則有可能是 CSRF 攻擊创译，可以拒絕該請求。
Referer Check 不僅能防范 CSRF 攻擊墙基，另一個(gè)應(yīng)用場景是 “防止圖片盜鏈”软族。 - 3.添加 token 驗(yàn)證
CSRF 攻擊之所以能夠成功，是因?yàn)楣粽呖梢酝耆珎卧煊脩舻恼埱蟛兄疲撜埱笾兴械挠脩趄?yàn)證信息都是存在于 Cookie 中立砸，因此攻擊者可以在不知道這些驗(yàn)證信息的情況下直接利用用戶自己的 Cookie 來通過安全驗(yàn)證。要抵御 CSRF痘拆，關(guān)鍵在于在請求中放入攻擊者所不能偽造的信息仰禽，并且該信息不存在于 Cookie 之中》那可以在 HTTP 請求中以參數(shù)的形式加入一個(gè)隨機(jī)產(chǎn)生的 token吐葵，并在服務(wù)器端建立一個(gè)攔截器來驗(yàn)證這個(gè) token，如果請求中沒有 token 或者 token 內(nèi)容不正確桥氏，則認(rèn)為可能是 CSRF 攻擊而拒絕該請求温峭。
