淺析CSRF攻擊

一、CSRF簡介

CSRF（Cross-site request forgery跨站請求僞造），也被稱為“one click attack”或者session riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用。

CSRF是一種依賴web浏覽器的、被混淆過的代理人攻擊（deputy attack）。

CSRF與之前說道XSS相比，出現比較少，流行度也不高，但是一旦出現，就是危害巨大的，難于防禦（因為影響業務和使用者體驗）。CSRF攻擊的本質是攻擊者盜用合法使用者的身份性，以使用者的名義進行非法操作。

二、CSRF進階

浏覽器所持有的Cookie分為兩種：一種是“Sesion Cookie”，又稱“臨時Cookie”；另一種是“Third-party Cookie”，也稱為“本地cookie”。兩者的差別在于，Third-party Cookie是伺服器在Set-Cookie時指定Expire時間，隻是到了Expire時間後Cookie才會失效，是以這種Cookie才會儲存在本地；Session Cookie則沒有指定Expire時間，是以關閉浏覽器，Session Cookie就會失效。

在浏覽網站的過程中，若是一個網站設定了Session Cookie，那麼在浏覽器的程序的生命周期内，及時浏覽器心打開一個Tab頁面，Session Cookie也是有效的，Session Cookie儲存在浏覽器程序的記憶體空間中。CSRF攻擊就是建立在會話之上的。

總結一下，CSRF攻擊需要兩個條件：

1、CSRF攻擊建立在浏覽器與伺服器的會話中；

2、欺騙使用者通路攻擊URL；

浏覽器也會有一些安全政策防禦，IE處于安全的考慮，預設禁止了浏覽器在<img>，<iframe>，<scrtpt>，<link>等标簽中發送第三方Cookie。而Firefox中，預設政策是允許發送第三方Cookie的。

P3P

P3P是一種被稱為個人隐私安全平台項目（the Platform for Privacy Preferences）的标準，能夠保護線上隐私權，使Internet沖浪者可以選擇在浏覽網頁時，是否被第三方收集并利用自己的個人資訊。如果一個站點不遵守P3P标準的話，那麼有關它的Cookies将被自動拒絕，并且P3P還能夠自動識破多種Cookies的嵌入方式。p3p是由全球資訊聯盟網所開發的。

随着Internet的發展，電子商務發展勢頭也異常迅猛。這種新的貿易方式在帶給人們難以想象的便利前提下，也給人們帶來了以往現金交易模式下所沒有的麻煩——通過網絡洩露個人隐私資料。(Platform for Privacy Preferences）正是一種可以提供這種個人隐私保護政策，并且正在被越來越多的技術人員接受的新技術。

Java實作：在Response的響應頭中加入

response.setHeader("P3P","CP=/"CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR/"");

請注意不要濫用該P3P屬性，以免帶來安全隐患。

CSRF攻擊成功的本質原因是重要操作的所有參數都是可以被攻擊者猜測到了。

三、CSRF的防禦

3.1 驗證碼

驗證碼是認為對抗CSRF攻擊最簡潔而有效的防禦方法。但是考慮到使用者的體驗效果，最好是在重要的操作再使用驗證碼。是以在支付的時候都可以看到再一次輸入密碼或者驗證碼的要求。

3.2 混淆參數

CSRF攻擊多是通過構造URL進行攻擊的，是以可以在URL請求中加入一些随機數或者混淆。

http://www.XXXXXX.com/XXXXX.php?url=rHfK000YH1eRCqsWBVUDjjv3ru5QictGyTrai04fZHnNCmGNz8Oyoc3XLJslxxiLK4Uhf91JVGzeFUXujPJ4iZlOFZKFZGlb7bU_TZMwAiSlA9D2-f4NdEuyQYp8UVXHBw1W0WY.7Y_ifkR5QZWY8BHCwKZWHaqhWKY5BWJI64qt7jHzk8sHfGmqx-OcO3ZgKfYt8-P1tA-BZZjdsRP5QfHPGmsSxH9LqrZd_sSxH9vUtr1dsSXej_SyZx8sSXej_LmIMAz1c_HZ4xl54xPmuCyr1Wgvy0.THdxnHf1PW6vnHD1PfKYTh7buy-b5Hm4njD0mvq1I7qzmy4o5H00TLNBTy-b5HDYn1m3PWDkn1RLnWnLP10zPWb0ugw4TARqnHD0uy-b5H00uyw-TvPGujYs0AP_pyPogLw4TARqn6KsUWYk0Zw-ThdGUh7_5H00XMfqTvN_u6KsTjYkP101rHnYP1c0mywGujYznH04n161P1DsPfKGTdqLpgF-UAN1T1Ys0AN3Ijd9mvP-TLPRXgK-rhdsr1VsIh-brWDYn1m3PWDkn1RLnWnLP10zPWberv-1N-PfrW0erLKzUvwdmLwRXgK-rWnknjcerLw1Tv-brMNGc10hmMPFUMPdTh78mvRWnBuBTY-8IhN1IankFhF1HAq9UBnz0APzm1YLPjRk&ck=2818.174.177.351.22.678.292.1631

3.3 Token

請求加入Token是目前防禦CSRF最好的方式，對應用的架構水準要求就高，使用者的會話有效期也不宜過長。

Token防禦的重點在于Token的生成、儲存、校驗、失效等方面。

1、Token生成：時間戳+随機數，長度16--20位即可，時間戳就是為了判斷Token是否失效；

2、Token隻能使用一次，而且隻在重要的操作時候進行校驗Token；

3、Token儲存：背景：分布式緩存系統中；前端頁面的标簽：<meta name="CSRF_Token" content="14232454567687456486796" />；

4、通過Javascript構造安全連結URL，并帶上Token；

本文轉自 夢朝思夕 51CTO部落格，原文連結:http://blog.51cto.com/qiangmzsx/1674208