簡介
??跨站點(diǎn)請求偽造(Cross Site Request Forgery,CSRF)：攻擊者首先在自己的域內(nèi)創(chuàng)建一個(gè)頁面吨铸，并偽造一個(gè)請求，然后誘使用戶點(diǎn)擊該頁面朱转，這樣就以該用戶的身份在第三方站點(diǎn)（攻擊者構(gòu)造的頁面）執(zhí)行了一次操作。
瀏覽器的cookie策略
??攻擊者偽造的請求之所以能夠被服務(wù)器驗(yàn)證通過，是因?yàn)橛脩舻臑g覽器成功的發(fā)送了cookie的緣故漾狼。
??瀏覽器所持有的cookie分為兩種：
- session cookie（又稱臨時(shí)cookie）
- third-party cookie（又稱本地cookie）
??兩者的區(qū)別在于third-party cookie是服務(wù)器在set-cookie時(shí)指定了expire時(shí)間，只要到了expire時(shí)間cookie就會失效饥臂。所以這種cookie會保存在本地逊躁。而session cookie則沒有指定expire時(shí)間，直到關(guān)閉瀏覽器后隅熙，session cookie才失效稽煤，他保存在瀏覽器進(jìn)程的內(nèi)存空間中核芽。
??有些瀏覽器，默認(rèn)策略允許發(fā)送第三方cookie酵熙，所以能夠成功發(fā)送用于認(rèn)證的third-party cookie轧简，CSRF攻擊成功。而有些瀏覽器默認(rèn)會攔截third-party cookie 匾二，這樣攻擊者則需要精心構(gòu)造攻擊環(huán)境哮独，比如誘使用戶在當(dāng)前瀏覽器先訪問目標(biāo)站點(diǎn)，使得session cookie有效察藐，在實(shí)CSRF攻擊皮璧。
P3P頭的副作用
??P3P Header 是W3C制定的一項(xiàng)關(guān)于隱私的標(biāo)準(zhǔn)，全稱是“the platform for privacy preferences”
??如果網(wǎng)站返回給瀏覽器的HTTP頭中包含有P3P頭转培，則在某種程度上來說恶导，將允許瀏覽器發(fā)送第三方cookie，P3P頭允許跨域訪問隱私數(shù)據(jù)浸须，從而可以跨域set-cookie成功惨寿。正因?yàn)镻3P頭目前在網(wǎng)站的應(yīng)用中被廣泛應(yīng)用，因此在CSRF防御中不能依賴于瀏覽器對第三方cookie的攔截策略删窒，不能心存僥幸裂垦。
構(gòu)造get/post 請求
Flash CSRF
??Flash有很多方式發(fā)起網(wǎng)絡(luò)請求，包括POST肌索、getURL蕉拢、loadvars等。
CSRF Worm
??即使沒有XSS漏洞诚亚，僅僅是CSRF也能發(fā)起大規(guī)模蠕蟲攻擊晕换。
CSRF的防御
驗(yàn)證碼
??CSRF的攻擊過程，往往在用戶不知情的的情況下構(gòu)造了網(wǎng)絡(luò)請求站宗，而驗(yàn)證碼則強(qiáng)制用戶必須與應(yīng)用進(jìn)行交互闸准，才能完成最終請求，但是有些時(shí)候出于用戶體驗(yàn)考慮梢灭，網(wǎng)站不能給所有的操作都加上驗(yàn)證嗎夷家，因此驗(yàn)證碼只能作為防御SCRF的一種輔助手段。
Referer Check
??Referer Check在網(wǎng)絡(luò)中常見的應(yīng)用就是“防止圖片盜鏈”敏释。同理Referer Check也可以被用于檢查請求是否來自合法的“源”库快。Referer Check的缺陷是：服務(wù)器并非什么時(shí)候都能取到Referer。
??很多用戶處于隱私保護(hù)的考慮钥顽，限制了Referer的發(fā)送义屏，在某些情況下，瀏覽器也不會發(fā)送Referer，（列：從https跳轉(zhuǎn)至HTTP湿蛔，出于安全考慮膀曾，瀏覽器也不會發(fā)送Referer）；有些Flash的版本可以發(fā)送自定義Referer的頭阳啥。因此我們無法依賴于Referer Check作為防御SCRF的主要手段，但是可以通過Referer Check來監(jiān)控CSRF攻擊的發(fā)生财喳。
Anti CSRF Token
現(xiàn)在業(yè)界針對CSRF防御察迟，一致做法是使用一個(gè)token。
CSRF的本質(zhì)
??CSRF能夠攻擊成功的本質(zhì)原因是：重要操作的所有參數(shù)都是可以被攻擊猜測到的耳高。攻擊者只有預(yù)測出URL的所有參數(shù)與參數(shù)值扎瓶，才能成功的構(gòu)造一個(gè)偽造的請求。
??因此可以想到：把參數(shù)加密泌枪，或者使用一些隨機(jī)數(shù)概荷，從而讓攻擊者無法猜測到參數(shù)值，這是“不可預(yù)測性原則”的一種應(yīng)用碌燕。
??在URL中误证，保持原參數(shù)不變，新增一個(gè)參數(shù)token修壕，這個(gè)token的值是隨機(jī)的愈捅，這樣由于token的存在，攻擊者無法在構(gòu)造出一個(gè)完整的URL實(shí)施CSRF攻擊慈鸠。
??token需要同時(shí)放在表單和session中蓝谨，再提交請求時(shí)，服務(wù)器只需驗(yàn)證表單中的token和用戶session（或cookie）中的token是否一致青团，如果一致譬巫，則認(rèn)為是合法請求；如果不一致督笆，或者有一為空芦昔，則認(rèn)為請求不合法，可能發(fā)生了CSRF攻擊胖腾。
Token的使用原則
??token的生成一定要足夠隨機(jī)烟零。
??可為token設(shè)置生命周期，可根據(jù)情況生成多個(gè)有效的token咸作。
??使用token時(shí)應(yīng)注意token的保密性锨阿。
安全防御的體系是相輔相成，缺一不可的记罚。
詳情請參考書籍
摘自：《白帽子講Web安全》 — 吳翰清
