引言：CSRF是一種網(wǎng)絡(luò)攻擊方式，該攻擊可以在受害者毫不知情的情況下以受害者名義偽造請求發(fā)送給受攻擊站點(diǎn)，從而在未授權(quán)的情況下執(zhí)行在權(quán)限保護(hù)之下的操作，具有很大的危害性。深刻理解CSRF的危害性，對CSRF的防范將會取得事半功倍的效果。

CSRF簡介

CSR F（Cross-siterequest forgery），中文名稱為跨站請求偽造，也被稱為CSRF/XSRF。

CSRF是一種網(wǎng)絡(luò)攻擊方式，該攻擊可以在受害者毫不知情的情況下以受害者名義偽造請求發(fā)送給受攻擊站點(diǎn)，從而在未授權(quán)的情況下執(zhí)行在權(quán)限保護(hù)之下的操作，具有很大的危害性。

可以這樣理解CSRF：攻擊者盜用了用戶的身份，以用戶的名義發(fā)送惡意請求，對服務(wù)器來說這個(gè)請求是完全合法的，但是卻完成了攻擊者所期望的一個(gè)操作，比如以用戶的名義發(fā)送郵件、發(fā)消息，盜取用戶的賬號，添加系統(tǒng)管理員等。

CSRF的形式

用戶如有以下行為，將可能受到攻擊:登錄受信任網(wǎng)站A，并在本地生成Cookie;在不登出A的情況下，訪問危險(xiǎn)網(wǎng)站B。

但除此之外，依舊不能保證以下情況不會發(fā)生：

1.不能保證登錄了一個(gè)網(wǎng)站后，不再打開一個(gè)Tab頁面并訪問另外的網(wǎng)站。

2.不能保證關(guān)閉瀏覽器后，用戶本地的Cookie立刻過期，上次的會話已經(jīng)結(jié)束。（事實(shí)上關(guān)閉瀏覽器不能結(jié)束一個(gè)會話）。

3.有些網(wǎng)站可能是一個(gè)存在其他漏洞的可信任的經(jīng)常被人訪問的網(wǎng)站。

CSRF攻擊分類

CSRF漏洞一般分為站外和站內(nèi)兩種類型。CSRF站外類型的漏洞本質(zhì)上就是傳統(tǒng)意義上的外部提交數(shù)據(jù)問題。通常程序員會考慮給一些留言或者評論的表單加上水印以防止SPAM問題，但是有時(shí)為了提高用戶的體驗(yàn)性，可能沒有對一些操作做任何限制，所以攻擊者可以事先預(yù)測并設(shè)置請求的參數(shù)，在站外的Web頁面里編寫腳本偽造文件請求，或者和自動提交的表單一起使用來實(shí)現(xiàn)GET、POST請求，當(dāng)用戶在會話狀態(tài)下點(diǎn)擊鏈接訪問站外Web頁面，客戶端就被強(qiáng)迫發(fā)起請求。

CSRF站內(nèi)類型的漏洞在一定程度上是由于程序員濫用$_REQUEST類變量造成的。在一些敏感的操作中（如修改密碼、添加用戶等），本來要求用戶從表單提交發(fā)起POST請求傳遞參數(shù)給程序，但是由于使用了$_REQUEST等變量，程序除支持接收POST請求傳遞的參數(shù)外也支持接收GET請求傳遞的參數(shù)，這樣就會為攻擊者使用CSRF攻擊創(chuàng)造條件。一般如果把預(yù)測的請求參數(shù)放在站內(nèi)或者留言的圖片鏈接中，用戶瀏覽了這樣的頁面就會被強(qiáng)迫發(fā)起這些請求。

CSRF攻擊是源于Web的隱式身份驗(yàn)證機(jī)制。Web的身份驗(yàn)證機(jī)制雖然可以保證一個(gè)請求是來自于某個(gè)用戶的瀏覽器，但卻無法保證該請求是用戶批準(zhǔn)發(fā)送的。

CSRF漏洞檢測

先抓取一個(gè)正常請求的數(shù)據(jù)包，然后去掉referer字段再重新提交，如果還是有效那基本上就存在問題了。當(dāng)然參數(shù)可能含有不能預(yù)測的參數(shù)（如userid之類），這個(gè)時(shí)候就看這個(gè)不可預(yù)測的參數(shù)能不能通過其他手段比如Flash拿到，如果能，則還是存在問題。還有就是試著改post為get，因?yàn)橛行┏绦蚴遣粎^(qū)分get/post的。

可以用一些專門針對CSRF漏洞進(jìn)行檢測的工具，如 CSRFTester，CSRF Request Builder等。

CSRF的防御

CSRF的防御可以從服務(wù)端和客戶端兩方面著手，防御效果是從服務(wù)端著手效果比較好，現(xiàn)在一般的CSRF防御也都在服務(wù)端進(jìn)行。

1.服務(wù)端進(jìn)行CSRF防御

服務(wù)端的CSRF方式方法很多樣，但總的思想都是一致的，就是在客戶端頁面增加偽隨機(jī)數(shù)。

Cookie Hashing(所有表單都包含同一個(gè)偽隨機(jī)值)：這可能是最簡單的解決方案了，因?yàn)楣粽卟荒塬@得第三方的Cookie(理論上)，所以表單中的數(shù)據(jù)也就構(gòu)造失敗了。這個(gè)方法已經(jīng)可以杜絕99%的CSRF攻擊了，還有1%由于用戶的Cookie很容易由于網(wǎng)站的XSS漏洞而被盜取，但是一般的攻擊者看到有需要算Hash值，基本都會放棄，某些除外，所以如果需要100%的杜絕，這個(gè)不是最好的方法。

驗(yàn)證碼：這個(gè)方案的思路是：每次的用戶提交都需要用戶在表單中填寫一個(gè)圖片上的隨機(jī)字符串。這個(gè)方案可以完全解決CSRF，但個(gè)人覺得在易用性方面似乎不是太好，還有是驗(yàn)證碼圖片的使用涉及了一個(gè)被稱為MHTML的Bug，可能在某些版本的微軟IE中受影響。

One-Time Tokens(不同的表單包含一個(gè)不同的偽隨機(jī)值)：在實(shí)現(xiàn)One-Time Tokens時(shí)，需要注意一點(diǎn)：就是“并行會話的兼容”。如果用戶在一個(gè)站點(diǎn)上同時(shí)打開了兩個(gè)不同的表單，CSRF保護(hù)措施不應(yīng)該影響到他對任何表單的提交。考慮一下如果每次表單被裝入時(shí)站點(diǎn)生成一個(gè)偽隨機(jī)值來覆蓋以前的偽隨機(jī)值將會發(fā)生什么情況：用戶只能成功地提交他最后打開的表單，因?yàn)樗衅渌谋韱味己蟹欠ǖ膫坞S機(jī)值。必須小心操作以確保CSRF保護(hù)措施不會影響選項(xiàng)卡式的瀏覽或者利用多個(gè)瀏覽器窗口瀏覽一個(gè)站點(diǎn)。

總結(jié)

CSRF攻擊作為一種存在已久的攻擊方式，在大量的商業(yè)網(wǎng)站上都可以找出。對廣大系統(tǒng)維護(hù)者來說需要深入理解CSRF攻擊，并制定最適合當(dāng)前系統(tǒng)的防御方案，在不損害應(yīng)用程序性能的前提下提高系統(tǒng)安全性,而對即將開發(fā)的網(wǎng)絡(luò)應(yīng)用系統(tǒng)來說，深刻理解CSRF的危害性，在設(shè)計(jì)階段就考慮到對CSRF的防范將會取得事半功倍的效果。