CSRF Cross Site Reqiest Forgery 跨站點請求僞造
CSRF 攻擊是利用用戶的身份操作用戶帳戶的一種攻擊方式
先 搭建一個 SAE 博客，上面可以上傳自己寫的html 用於後面的csrf 頁面
參考： http://jingyan.baidu.com/article/020278118f30e11bcc9ce595.html
在SAE上安裝： http://docs.typecho.org/sae-install
eg: 自己博客上上傳一個xxx.html 然後構造<img src=http://xxx.com/xxx.do?delete&id=xxxx/> 然後發送這個html 網址給對方，對方一經訪問就刪除了xxx文章.
我測試了一下，用chrome 實驗 CSDN 不行，我抓包查看 發現 能正常刪除文章的 請求 是 XMLHttpRequest，爲 Ajax 異步請求。但是失敗原因不是它，失敗原因是referer 不同
COOKIE :
1 Session Cookie 臨時cookie
沒有指定Expire時間，瀏覽器關閉後，COOKIE 就失效了
在瀏覽網站的過程中，若是一個網站設置了Session Cookie,那麼在瀏覽器的生命週期中，即使瀏覽器新打開了TAB頁面，Session Cookie 也都是有效的。
Session Cookie 保存在瀏覽器進程的內存空間中
2: Third-party Cookie 本地Cookie
是服務器在Ser-Cookie 時指定了 Expire 時間,只有到了 Expire時間後，cookie 纔會失效，所以保存在本地
Third-party Cookie 保存在 本地
<script> <img> <iframe> <link> 等標籤禁止在 IE 瀏覽器 發送第三方cookie
FireFox 默認策略是允許 發送第三方cookie
有沒有辦法不讓瀏覽器刷新 ： <iframe>
p3p header Thr Platform for Privacy Preferences
如果網站返回給瀏覽器的HTTP頭中包含P3P頭，則在某種程度上，允許瀏覽器發送第三頭 cookie.
在IE下 即使是 <iframe> <script> 等標籤都不再攔截 第三方 cookie
主要用於 類似廣告的需要跨域訪問的頁面，設置後，對於COOKIE 影響將擴大到整個域中所有頁面，cookie 是以域和path爲單位的
flash csrf:
import flash.net.URLRequest;
import flash.system.Security;
var url = new URLRequest("http://xxx/xxx");
var param = new URLVariables();
param = "test=123";
url.method = "POST";
url.data = param;
sendToURL(url);
stop();eq = new LoadVars();
req.addRequestHeader("foo","bar");
req.send("http://xxx/xxx?v1=123&v2=456","_blank","GET");防禦：
1） 驗證碼
強制用戶必須與應用進行交互，才能完成最終請求，因此在通常情況下，驗證碼可以很好地遏制 CSRF攻擊
考慮到用戶體驗，只能作爲輔助手段
2）referer check
最常見的應用 就是 “防止圖片盜鏈”。同理，也可以作爲檢查請求是否來自合法的 “源”
假如一個 “論壇發帖” 的操作，那麼referer 的值必然是 發帖表單所在的頁面，如果referer不是這個頁面，甚至不是發帖網站的域，那麼就極可能是 CSRF攻擊了
缺陷：在於 服務器不是什麼時候都能取到referer 的，很多時候出於隱私保護的考慮，限制了 rerer的發送， 還有HTTPS 到HTTP的跳轉，出於安全考慮，瀏覽器也不會發送 referer的
所有跨協議傳遞的請求都是不會送referer的，如https->http,(這個利用成本有點高）還有javascript->http,data->http
在flash的一些版本中，曾經可以 發送自定義的 referer 頭，雖然flash 在新版本中已經做了安全限制了，不再允許自動以 referer頭，但難免不會有別的客戶端的插件允許這種操作
3） 業界的一致做法是使用一個 token
CSRF 本質——重要操作的所有參數能夠被攻擊者猜到。
把參數加密，或者使用一些隨機數，從而讓攻擊者無法猜到參數值。這事“不可預測性原則”
比如一個刪除操作URL： http://xxx/dekete?username=abc&item=123 將username 加密
http://xxx/dekete?username=md5(salt+abc)&item=123
這樣在攻擊者不知道 salt 的情況下無法構造URL，無法發起CSRF，而服務器可以知道
缺陷： 加密或者混淆後URL將變得非常難讀，對用戶非常不友好，其次，如果加密的參數每次都改變，則某些URL將無法再被用戶收藏
anti csrf token:
http://xxx/delete?username=abc&item=123&token=[random(seed)]
token需要足夠隨機，實際應用中 token可以在用戶的session 中，或者瀏覽器的 cookie中
每次請求生成一個新的 token,中，那麼可以考慮生成多個 有效的 token,以解決多頁面共存問題
儘量把 token放在 表單中，防止token泄漏（否則referer中可以查到toen）,把敏感操作由GET 換成 POST 以form的形式提交，可以避免token的泄漏
在XSS攻擊下，攻擊者完全可以請求頁面後，讀出頁面的內容的token值，然後再構造一個合法的請求，這個過程稱爲 XSRF
在自己的域上構造 html
<html>
<iframe src="data:text/html;base64,base64(<script src=http://xxx/delete?articleId=xxx></script>)" ></iframe>
</html>看到 CSDN 有 access-token 那麼幾種防護都設置了的!