知識星球來自：區塊鏈技術聯盟
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，是一種對網站的惡意利用。
上圖為CSRF攻擊的一個簡單模型，使用者訪問惡意網站B，惡意網站B傳回給使用者的HTTP資訊中要求使用者訪問網站A，而由於使用者和網站A之間可能已經有信任關係導致這個請求就像使用者真實傳送的一樣會被執行。
二、CSRF攻擊的危害
攻擊者盜用了你的身份，以你的名義傳送惡意請求，對伺服器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作，比如以你的名義傳送郵件、發訊息，盜取你的賬號，新增系統管理員，甚至於購買商品、虛擬貨幣轉賬等。
如果CSRF傳送的垃圾資訊還帶有蠕蟲連結的話，那些接收到這些有害資訊的好友萬一開啟私信中的連線就也成為了有害資訊的散播著，這樣數以萬計的使用者被竊取了資料種植了木馬。整個網站的應用就可能在瞬間奔潰，使用者投訴，使用者流失，公司聲譽一落千丈甚至面臨倒閉。曾經在MSN上，一個美國的19歲的小夥子Samy利用css的background漏洞幾小時內讓100多萬使用者成功的感染了他的蠕蟲，雖然這個蠕蟲並沒有破壞整個應用，只是在每一個使用者的簽名後面都增加了一句“Samy 是我的偶像”，但是一旦這些漏洞被惡意使用者利用，後果將不堪設想，同樣的事情也曾經發生在新浪微博上面。
如下：其中Web A為存在CSRF漏洞的網站，Web B為攻擊者構建的惡意網站，User C為Web A網站的合法使用者。
三、CSRF攻擊原理及過程
1 、使用者C開啟瀏覽器，訪問受信任網站A，輸入使用者名稱和密碼請求登入網站A；
2、在使用者資訊透過驗證後，網站A產生Cookie資訊並傳回給瀏覽器，此時使用者登入網站A成功，可以正常傳送請求到網站A；
3、使用者未退出網站A之前，在同一瀏覽器中，開啟一個TAB頁訪問網站B；
4、網站B接收到使用者請求後，傳回一些攻擊性程式碼，併發出一個請求要求訪問第三方站點A；
5.、瀏覽器在接收到這些攻擊性程式碼後，根據網站B的請求，在使用者不知情的情況下攜帶Cookie資訊，向網站A發出請求。網站A並不知道該請求其實是由B發起的，所以會根據使用者C的Cookie資訊以C的許可權處理該請求，導致來自網站B的惡意程式碼被執行。
舉例：
簡單版：
假如部落格園有個加關註的GET介面，blogUserGuid引數很明顯是關註人Id，如下：
那我只需要在我的一篇博文內容裡面寫一個img標簽：
那麼只要有人開啟我這篇博文，那就會自動關註我。
升級版：
假如部落格園還是有個加關註的介面，不過已經限制了只獲取POST請求的資料。這個時候就做一個第三方的頁面，但裡麵包含form提交程式碼，然後透過QQ、郵箱等社交工具傳播，誘惑使用者去開啟，那開啟過部落格園的使用者就中招了。
在說例子之前要糾正一個iframe問題，有人會直接在第三方頁面這樣寫。如下：
這樣是用問題的，由於同源策略的原因，iframe內容根本載入不出來，所以裡面form提交當然不會執行。
PS：我嘗試了chrome、IE11、Firefox，情況都是這樣。
所以可以用嵌多一層頁面方式解決，如下：
第一個展示頁面（test）:
第二個隱藏頁面（test2）:
這樣就可以解決了，有人會問為什麼要加多一層iframe，因為不嵌iframe頁面會重定向，這樣就降低了攻擊的隱蔽性。另外我們test頁面不使用XMLHTTPRequest傳送POST請求，是因為有跨域的問題，而form可以跨域post資料。
進階版：
假如部落格園還是有個加關註的介面，已經限制POST，但博文內容是直接貼進HTML（未過濾），那就遭受XSS攻擊。那麼就可以直接把上面程式碼嵌入博文，那麼只要有人開啟我這篇博文，還是會自動關註我，這組合攻擊方式稱為XSRF。
四、CSRF漏洞檢測
檢測CSRF漏洞是一項比較繁瑣的工作，最簡單的方法就是抓取一個正常請求的資料包，去掉Referer欄位後再重新提交，如果該提交還有效，那麼基本上可以確定存在CSRF漏洞。
隨著對CSRF漏洞研究的不斷深入，不斷湧現出一些專門針對CSRF漏洞進行檢測的工具，如CSRFTester，CSRF Request Builder。
以CSRFTester工具為例，CSRF漏洞檢測工具的測試原理如下：
使用CSRFTester進行測試時，首先需要抓取我們在瀏覽器中訪問過的所有連結以及所有的表單等資訊，然後透過在CSRFTester中修改相應的表單等資訊，重新提交，這相當於一次偽造客戶端請求。如果修改後的測試請求成功被網站伺服器接受，則說明存在CSRF漏洞，當然此款工具也可以被用來進行CSRF攻擊。
五、CSRF漏洞防禦
目前防禦 CSRF 攻擊主要有三種策略：驗證 HTTP Referer 欄位；在請求地址中新增 token 並驗證；在 HTTP 頭中自定義屬性並驗證。
1、儘量使用POST，限制GET
GET介面太容易被拿來做CSRF攻擊，看第一個示例就知道，只要構造一個img標簽，而img標簽又是不能過濾的資料。
介面最好限製為POST使用，GET則無效，降低攻擊風險。
當然POST並不是萬無一失，攻擊者只要構造一個form就可以，但需要在第三方頁面做，這樣就增加暴露的可能性。
2、瀏覽器Cookie策略
IE6、7、8、Safari會預設攔截第三方本地Cookie（Third-party Cookie）的傳送。
但是Firefox2、3、Opera、Chrome、Android等不會攔截，所以透過瀏覽器Cookie策略來防禦CSRF攻擊不靠譜，只能說是降低了風險。
PS：Cookie分為兩種
Session Cookie（在瀏覽器關閉後，就會失效，儲存到記憶體裡），
Third-party Cookie（即只有到了Exprie時間後才會失效的Cookie，這種Cookie會儲存到本地）。
PS：另外如果網站傳回HTTP頭包含P3P Header，那麼將允許瀏覽器傳送第三方Cookie。
3、加驗證碼
驗證碼，強制使用者必須與應用進行互動，才能完成最終請求。在通常情況下，驗證碼能很好遏制CSRF攻擊。
但是出於使用者體驗考慮，網站不能給所有的操作都加上驗證碼。
因此驗證碼只能作為一種輔助手段，不能作為主要解決方案。
4、Referer Check
Referer Check在Web最常見的應用就是“防止圖片盜鏈”。
同理，Referer Check也可以被用於檢查請求是否來自合法的“源”（Referer值是否是指定頁面，或者網站的域），如果都不是，那麼就極可能是CSRF攻擊。
但是因為伺服器並不是什麼時候都能取到Referer，所以也無法作為CSRF防禦的主要手段。
但是用Referer Check來監控CSRF攻擊的發生，倒是一種可行的方法。
5 、Anti CSRF Token
現在業界對CSRF的防禦，一致的做法是使用一個Token（Anti CSRF Token）。
例子：
1、使用者訪問某個表單頁面。
2、 服務端生成一個Token，放在使用者的Session中，或者瀏覽器的Cookie中。
3、在頁面表單附帶上Token引數。
4、使用者提交請求後， 服務端驗證表單中的Token是否與使用者Session（或Cookies）中的Token一致，一致為合法請求，不是則非法請求。
這個Token的值必須是隨機的，不可預測的。由於Token的存在，攻擊者無法再構造一個帶有合法Token的請求實施CSRF攻擊。另外使用Token時應註意Token的保密性，儘量把敏感操作由GET改為POST，以form或AJAX形式提交，避免Token洩露。
註意：
CSRF的Token僅僅用於對抗CSRF攻擊。當網站同時存在XSS漏洞時候，那這個方案也是空談。
所以XSS帶來的問題，應該使用XSS的防禦方案予以解決。
特別是在一些論壇之類支援使用者自己發表內容的網站，駭客可以在上面釋出自己個人網站的地址。由於系統也會在這個地址後面加上 token，駭客可以在自己的網站上得到這個 token，並馬上就可以發動 CSRF 攻擊。為了避免這一點，系統可以在新增 token 的時候增加一個判斷，如果這個連結是鏈到自己本站的，就在後面新增 token，如果是通向外網則不加。不過，即使這個 csrftoken 不以引數的形式附加在請求之中，駭客的網站也同樣可以透過 Referer 來得到這個 token 值以發動 CSRF 攻擊。這也是一些使用者喜歡手動關閉瀏覽器 Referer 功能的原因。
5、在 HTTP 頭中自定義屬性並驗證
這種方法也是使用 token 併進行驗證，和上一種方法不同的是，這裡並不是把 token 以引數的形式置於 HTTP 請求之中，而是把它放到 HTTP 頭中自定義的屬性裡。透過 XMLHttpRequest 這個類，可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，並把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便，同時，透過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的位址列，也不用擔心 token 會透過 Referer 洩露到其他網站中去。
然而這種方法的侷限性非常大。XMLHttpRequest 請求通常用於 Ajax 方法中對於頁面區域性的非同步掃清，並非所有的請求都適合用這個類來發起，而且透過該類請求得到的頁面不能被瀏覽器所記錄下，從而進行前進，後退，掃清，收藏等操作，給使用者帶來不便。另外，對於沒有進行 CSRF 防護的遺留系統來說，要採用這種方法來進行防護，要把所有請求都改為 XMLHttpRequest 請求，這樣幾乎是要重寫整個網站，這代價無疑是不能接受的。
六、最後聊聊XSS
惡意攻擊者往Web頁面裡插入惡意Script程式碼，當使用者瀏覽該頁之時，嵌入其中Web裡面的Script程式碼會被執行，從而達到惡意攻擊使用者的目的。
XSS攻擊分成兩類
來自內部的攻擊：
主要指的是利用程式自身的漏洞，構造跨站陳述句，如:dvbbs的showerror.asp存在的跨站漏洞。
來自外部的攻擊
主要指的自己構造XSS跨站漏洞網頁或者尋找非標的機以外的有跨站漏洞的網頁。如當我們要滲透一個站點，我們自己構造一個有跨站漏洞的網頁，然後構造跨站陳述句，透過結合其它技術，如社會工程學等，欺騙標的伺服器的管理員開啟。
XSS分為：儲存型和反射型
儲存型XSS：
儲存型XSS，持久化，程式碼是儲存在伺服器中的，如在個人資訊或發表文章等地方，加入程式碼，如果沒有過濾或過濾不嚴，那麼這些程式碼將儲存到伺服器中，使用者訪問該頁面的時候觸發程式碼執行。這種XSS比較危險，容易造成蠕蟲，盜竊cookie（雖然還有種DOM型XSS，但是也還是包括在儲存型XSS內）。
反射型XSS：
非持久化，需要欺騙使用者自己去點選連結才能觸發XSS程式碼（伺服器中沒有這樣的頁面和內容），一般容易出現在搜尋頁面。
●編號574，輸入編號直達本文
●輸入m獲取文章目錄
大資料與人工智慧
更多推薦《18個技術類公眾微信》
涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
