Web安全CSRF攻击与防御
來自：區(qū)塊鏈技術(shù)聯(lián)盟
https://www.toutiao.com/a6514792395601609223/
參考：
http://blog.csdn.net/stpeace/article/details/53512283
https://www.cnblogs.com/lovesong/p/5233195.html
目錄：
一、CSRF介紹
二、CSRF攻擊的危害
三、CSRF攻擊原理及過程
四、CSRF漏洞檢測
五、CSRF漏洞預防
六、最后聊聊xss
一、CSRF介紹
CSRF（Cross-site request forgery）
跨站請求偽造，也被稱為“OneClick Attack”或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網(wǎng)站的惡意利用。
上圖為CSRF攻擊的一個簡單模型，用戶訪問惡意網(wǎng)站B，惡意網(wǎng)站B返回給用戶的HTTP信息中要求用戶訪問網(wǎng)站A，而由于用戶和網(wǎng)站A之間可能已經(jīng)有信任關(guān)系導致這個請求就像用戶真實發(fā)送的一樣會被執(zhí)行。
二、CSRF攻擊的危害
攻擊者盜用了你的身份，以你的名義發(fā)送惡意請求，對服務(wù)器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作，比如以你的名義發(fā)送郵件、發(fā)消息，盜取你的賬號，添加系統(tǒng)管理員，甚至于購買商品、虛擬貨幣轉(zhuǎn)賬等。?
如果CSRF發(fā)送的垃圾信息還帶有蠕蟲鏈接的話，那些接收到這些有害信息的好友萬一打開私信中的連接就也成為了有害信息的散播著，這樣數(shù)以萬計的用戶被竊取了資料種植了木馬。整個網(wǎng)站的應(yīng)用就可能在瞬間奔潰，用戶投訴，用戶流失，公司聲譽一落千丈甚至面臨倒閉。曾經(jīng)在MSN上，一個美國的19歲的小伙子Samy利用css的background漏洞幾小時內(nèi)讓100多萬用戶成功的感染了他的蠕蟲，雖然這個蠕蟲并沒有破壞整個應(yīng)用，只是在每一個用戶的簽名后面都增加了一句“Samy 是我的偶像”，但是一旦這些漏洞被惡意用戶利用，后果將不堪設(shè)想，同樣的事情也曾經(jīng)發(fā)生在新浪微博上面。
如下：其中Web A為存在CSRF漏洞的網(wǎng)站，Web B為攻擊者構(gòu)建的惡意網(wǎng)站，User C為Web A網(wǎng)站的合法用戶。
三、CSRF攻擊原理及過程
1 、用戶C打開瀏覽器，訪問受信任網(wǎng)站A，輸入用戶名和密碼請求登錄網(wǎng)站A；
2、在用戶信息通過驗證后，網(wǎng)站A產(chǎn)生Cookie信息并返回給瀏覽器，此時用戶登錄網(wǎng)站A成功，可以正常發(fā)送請求到網(wǎng)站A；
3、用戶未退出網(wǎng)站A之前，在同一瀏覽器中，打開一個TAB頁訪問網(wǎng)站B；
4、網(wǎng)站B接收到用戶請求后，返回一些攻擊性代碼，并發(fā)出一個請求要求訪問第三方站點A；
5.、瀏覽器在接收到這些攻擊性代碼后，根據(jù)網(wǎng)站B的請求，在用戶不知情的情況下攜帶Cookie信息，向網(wǎng)站A發(fā)出請求。網(wǎng)站A并不知道該請求其實是由B發(fā)起的，所以會根據(jù)用戶C的Cookie信息以C的權(quán)限處理該請求，導致來自網(wǎng)站B的惡意代碼被執(zhí)行。
舉例：
簡單版：
假如博客園有個加關(guān)注的GET接口，blogUserGuid參數(shù)很明顯是關(guān)注人Id，如下：
那我只需要在我的一篇博文內(nèi)容里面寫一個img標簽：
那么只要有人打開我這篇博文，那就會自動關(guān)注我。
升級版：
假如博客園還是有個加關(guān)注的接口，不過已經(jīng)限制了只獲取POST請求的數(shù)據(jù)。這個時候就做一個第三方的頁面，但里面包含form提交代碼，然后通過QQ、郵箱等社交工具傳播，誘惑用戶去打開，那打開過博客園的用戶就中招了。
在說例子之前要糾正一個iframe問題，有人會直接在第三方頁面這樣寫。如下：
這樣是用問題的，由于同源策略的原因，iframe內(nèi)容根本加載不出來，所以里面form提交當然不會執(zhí)行。
PS：我嘗試了chrome、IE11、Firefox，情況都是這樣。
所以可以用嵌多一層頁面方式解決，如下：
第一個展示頁面（test）:
第二個隱藏頁面（test2）:
這樣就可以解決了，有人會問為什么要加多一層iframe，因為不嵌iframe頁面會重定向，這樣就降低了攻擊的隱蔽性。另外我們test頁面不使用XMLHTTPRequest發(fā)送POST請求，是因為有跨域的問題，而form可以跨域post數(shù)據(jù)。
進階版：
假如博客園還是有個加關(guān)注的接口，已經(jīng)限制POST，但博文內(nèi)容是直接貼進HTML（未過濾），那就遭受XSS攻擊。那么就可以直接把上面代碼嵌入博文，那么只要有人打開我這篇博文，還是會自動關(guān)注我，這組合攻擊方式稱為XSRF。
四、CSRF漏洞檢測
檢測CSRF漏洞是一項比較繁瑣的工作，最簡單的方法就是抓取一個正常請求的數(shù)據(jù)包，去掉Referer字段后再重新提交，如果該提交還有效，那么基本上可以確定存在CSRF漏洞。
隨著對CSRF漏洞研究的不斷深入，不斷涌現(xiàn)出一些專門針對CSRF漏洞進行檢測的工具，如CSRFTester，CSRF Request Builder。
以CSRFTester工具為例，CSRF漏洞檢測工具的測試原理如下：
使用CSRFTester進行測試時，首先需要抓取我們在瀏覽器中訪問過的所有鏈接以及所有的表單等信息，然后通過在CSRFTester中修改相應(yīng)的表單等信息，重新提交，這相當于一次偽造客戶端請求。如果修改后的測試請求成功被網(wǎng)站服務(wù)器接受，則說明存在CSRF漏洞，當然此款工具也可以被用來進行CSRF攻擊。
五、CSRF漏洞防御
目前防御 CSRF 攻擊主要有三種策略：驗證 HTTP Referer 字段；在請求地址中添加 token 并驗證；在 HTTP 頭中自定義屬性并驗證。
1、盡量使用POST，限制GET
GET接口太容易被拿來做CSRF攻擊，看第一個示例就知道，只要構(gòu)造一個img標簽，而img標簽又是不能過濾的數(shù)據(jù)。
接口最好限制為POST使用，GET則無效，降低攻擊風險。
當然POST并不是萬無一失，攻擊者只要構(gòu)造一個form就可以，但需要在第三方頁面做，這樣就增加暴露的可能性。
2、瀏覽器Cookie策略
IE6、7、8、Safari會默認攔截第三方本地Cookie（Third-party Cookie）的發(fā)送。
但是Firefox2、3、Opera、Chrome、Android等不會攔截，所以通過瀏覽器Cookie策略來防御CSRF攻擊不靠譜，只能說是降低了風險。
PS：Cookie分為兩種
Session Cookie（在瀏覽器關(guān)閉后，就會失效，保存到內(nèi)存里），
Third-party Cookie（即只有到了Exprie時間后才會失效的Cookie，這種Cookie會保存到本地）。
PS：另外如果網(wǎng)站返回HTTP頭包含P3P Header，那么將允許瀏覽器發(fā)送第三方Cookie。
3、加驗證碼
驗證碼，強制用戶必須與應(yīng)用進行交互，才能完成最終請求。在通常情況下，驗證碼能很好遏制CSRF攻擊。
但是出于用戶體驗考慮，網(wǎng)站不能給所有的操作都加上驗證碼。
因此驗證碼只能作為一種輔助手段，不能作為主要解決方案。
4、Referer Check
Referer Check在Web最常見的應(yīng)用就是“防止圖片盜鏈”。
同理，Referer Check也可以被用于檢查請求是否來自合法的“源”（Referer值是否是指定頁面，或者網(wǎng)站的域），如果都不是，那么就極可能是CSRF攻擊。
但是因為服務(wù)器并不是什么時候都能取到Referer，所以也無法作為CSRF防御的主要手段。
但是用Referer Check來監(jiān)控CSRF攻擊的發(fā)生，倒是一種可行的方法。
5 、Anti CSRF Token
現(xiàn)在業(yè)界對CSRF的防御，一致的做法是使用一個Token（Anti CSRF Token）。
例子：
1、用戶訪問某個表單頁面。
2、 服務(wù)端生成一個Token，放在用戶的Session中，或者瀏覽器的Cookie中。
3、在頁面表單附帶上Token參數(shù)。
4、用戶提交請求后， 服務(wù)端驗證表單中的Token是否與用戶Session（或Cookies）中的Token一致，一致為合法請求，不是則非法請求。
這個Token的值必須是隨機的，不可預測的。由于Token的存在，攻擊者無法再構(gòu)造一個帶有合法Token的請求實施CSRF攻擊。另外使用Token時應(yīng)注意Token的保密性，盡量把敏感操作由GET改為POST，以form或AJAX形式提交，避免Token泄露。
注意：
CSRF的Token僅僅用于對抗CSRF攻擊。當網(wǎng)站同時存在XSS漏洞時候，那這個方案也是空談。
所以XSS帶來的問題，應(yīng)該使用XSS的防御方案予以解決。
特別是在一些論壇之類支持用戶自己發(fā)表內(nèi)容的網(wǎng)站，黑客可以在上面發(fā)布自己個人網(wǎng)站的地址。由于系統(tǒng)也會在這個地址后面加上 token，黑客可以在自己的網(wǎng)站上得到這個 token，并馬上就可以發(fā)動 CSRF 攻擊。為了避免這一點，系統(tǒng)可以在添加 token 的時候增加一個判斷，如果這個鏈接是鏈到自己本站的，就在后面添加 token，如果是通向外網(wǎng)則不加。不過，即使這個 csrftoken 不以參數(shù)的形式附加在請求之中，黑客的網(wǎng)站也同樣可以通過 Referer 來得到這個 token 值以發(fā)動 CSRF 攻擊。這也是一些用戶喜歡手動關(guān)閉瀏覽器 Referer 功能的原因。
5、在 HTTP 頭中自定義屬性并驗證
這種方法也是使用 token 并進行驗證，和上一種方法不同的是，這里并不是把 token 以參數(shù)的形式置于 HTTP 請求之中，而是把它放到 HTTP 頭中自定義的屬性里。通過 XMLHttpRequest 這個類，可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，并把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便，同時，通過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的地址欄，也不用擔心 token 會透過 Referer 泄露到其他網(wǎng)站中去。
然而這種方法的局限性非常大。XMLHttpRequest 請求通常用于 Ajax 方法中對于頁面局部的異步刷新，并非所有的請求都適合用這個類來發(fā)起，而且通過該類請求得到的頁面不能被瀏覽器所記錄下，從而進行前進，后退，刷新，收藏等操作，給用戶帶來不便。另外，對于沒有進行 CSRF 防護的遺留系統(tǒng)來說，要采用這種方法來進行防護，要把所有請求都改為 XMLHttpRequest 請求，這樣幾乎是要重寫整個網(wǎng)站，這代價無疑是不能接受的。
六、最后聊聊XSS
惡意攻擊者往Web頁面里插入惡意Script代碼，當用戶瀏覽該頁之時，嵌入其中Web里面的Script代碼會被執(zhí)行，從而達到惡意攻擊用戶的目的。
XSS攻擊分成兩類
來自內(nèi)部的攻擊：
主要指的是利用程序自身的漏洞，構(gòu)造跨站語句，如:dvbbs的showerror.asp存在的跨站漏洞。
來自外部的攻擊
主要指的自己構(gòu)造XSS跨站漏洞網(wǎng)頁或者尋找非目標機以外的有跨站漏洞的網(wǎng)頁。如當我們要滲透一個站點，我們自己構(gòu)造一個有跨站漏洞的網(wǎng)頁，然后構(gòu)造跨站語句，通過結(jié)合其它技術(shù)，如社會工程學等，欺騙目標服務(wù)器的管理員打開。
XSS分為：存儲型和反射型
存儲型XSS：
存儲型XSS，持久化，代碼是存儲在服務(wù)器中的，如在個人信息或發(fā)表文章等地方，加入代碼，如果沒有過濾或過濾不嚴，那么這些代碼將儲存到服務(wù)器中，用戶訪問該頁面的時候觸發(fā)代碼執(zhí)行。這種XSS比較危險，容易造成蠕蟲，盜竊cookie（雖然還有種DOM型XSS，但是也還是包括在存儲型XSS內(nèi)）。
反射型XSS：
非持久化，需要欺騙用戶自己去點擊鏈接才能觸發(fā)XSS代碼（服務(wù)器中沒有這樣的頁面和內(nèi)容），一般容易出現(xiàn)在搜索頁面。
總結(jié)
以上是生活随笔為你收集整理的Web安全CSRF攻击与防御的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【Unity3D基础2-2】认识Unit
- 下一篇： oauth2基本概念