聲明：轉自 http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
XSS攻擊：跨站腳本攻擊(Cross Site Scripting)黑客通過js代碼劫持我跟服務器之間的會話，這還不是最危險的，來看看下面這句話：
“Session ID不能從硬盤上的Cookie文件獲得，如果想在客戶端獲知自己的Session ID，只能通過Javascrīpt來讀取。”XSS攻擊+CSRF攻擊才是最致命的。
CSRF：從一個網站A中發起一個到網站B的請求，而這個請求是經過了偽裝的，偽裝操作達到的目的就是讓請求看起來像是從網站B中發起的，也就是說，讓B網站所在的服務器端誤以為該請求是從自己網站發起的，而不是從A網站發起的。當然，請求一般都是惡意的。
一、什么是CSRF？
CSRF是Cross Site Request Forgery的縮寫，翻譯過來就是跨站請求偽造。那么什么是跨站請求偽造呢？讓我一個詞一個詞的解釋：
1、跨站：顧名思義，就是從一個網站到另一個網站。
2、請求：即HTTP請求。
3、偽造：在這里可以理解為仿造、偽裝。
綜合起來的意思就是：從一個網站A中發起一個到網站B的請求，而這個請求是經過了偽裝的，偽裝操作達到的目的就是讓請求看起來像是從網站B中發起的，也就是說，讓B網站所在的服務器端誤以為該請求是從自己網站發起的，而不是從A網站發起的。當然，請求一般都是惡意的。
看到這里，你可能會問：為什么要偽裝成從B網站發起的呢？從網站A直接向B網站服務器發起請求不可以嗎？
要回答這個問題，就需要我們對Cookie機制有一定的認識。關於Cookie機制我會單獨寫一篇文章，這里不做詳細介紹。這里你只需要知道：之所以要偽裝成從B網站發起的，是因為Cookie是不能跨域發送的。結合上面這個例子來說就是：如果從A網站直接發送請求到B網站服務器的話，是無法將B網站中產生的Cookie一起發給B服務器的。
可能你還會問，為什么非要發送Cookie呢？這是因為服務器在用戶登錄后會將用戶的一些信息放到Cookie中返回給客戶端，然后客戶端在請求一些需要認證的資源的時候會把Cookie一起發給服務器，服務器通過讀取Cookie中的信息來進行用戶認證，認證通過后才會做出正確的響應。
A網站訪問B網站服務器的一些需要認證的資源的時候，如果沒有Cookie信息，服務器是拒絕訪問的，那么A網站就無法進行惡意操作。而偽造成B網站的請求，就可以將B網站的Cookie一起發到B服務器，這個時候就服務器就認為該請求是合法的，就會給出正確的響應，這個時候，A網站就達到目的了。
簡單一句話就是：攻擊者盜用了你的身份，以你的名義發送惡意請求。
那么，A網站通過CSRF能夠做那些操作呢？
二、CSRF能夠做什么呢？
CSRF能夠做的事情包括：以你名義發送郵件，發消息，盜取你的賬號，甚至於購買商品，虛擬貨幣轉賬……造成的問題包括：個人隱私泄露以及財產安全。等等等等。
三、通俗點的例子
下面我們舉個例子來說明CSRF攻擊是如何實現的。
假設有一個微博網站B，B有一個“加關注”的功能，即一個用戶可以關注另一個用戶，而這個功能是這樣的實現的：用戶每次點擊“加關注”按鈕的時候，就會向服務器發送一個GET請求，URL如下：
http://www.bdomain.com/addfriends?uid=123URL中的參數uid表示的是你要關注的用戶的ID。
在正常情況下，即你登錄B網站后，點擊“加關注”按鈕，瀏覽器會將上面的URL連同B網站產生的Cookie一起發送到B網站的服務器，B服務器首先通過Cookie進行用戶認證，如果Cookie中的信息正確，就會進行向數據庫中寫入記錄，這樣，你就成功關注了ID為123的用戶。
假如我是一個惡意用戶，我想讓更多的人關注我，而我又不想通過正常的渠道去實現，因為畢竟正常渠道比較浪費時間，於是我便開始想歪主意，碰巧，B網站的“加關注”的實現原理被我發現了。這個時候，我便進行了如下操作：
首先我在我自己的網站A里發了篇文章，文章中全是妖嬈的美女圖片，大家都喜歡美女嘛，所以就會有很多人來看我的這些美女，我們知道，圖片在網頁中大都是通過<img scr=”http://….”/>這樣的形式實現的，圖片加載的時候就會請求src中指定的URL，而我就把眾多美女圖片的src寫成了B博客里“加關注”的URL，不同的是將參數uid的值都寫成了我在B網站中的ID（假設是456），即：
http://www.bdomain.com/addfriends?uid=456在網站A中的代碼中就是：<img src=”http://www.bdomain.com/addfriends?uid=456″ />，當用戶點擊我發的文章的時候，瀏覽器就會請求這個src中的URL，這樣就達到了在A網站中請求B服務器資源的目的，但是這樣還差了一步，因為請求還是從A網站發出的，所以就沒有B網站產生的Cookie，所以還是達不到目的，那該怎樣做呢？
這就需要利用用戶的上網習慣了，我們平時都會同時瀏覽很多網頁，比如，你打開瀏覽器登錄了B網站，與此同時，你可能也打開了我的網站A，而碰巧被我網站里全是美女的帖子吸引住了，就忍不住打開了這個帖子，這個時候，我的網站A就發起了上面的那個到B服務器的請求，而此時，你已經登錄了B網站，Cookie已經產生了，瀏覽器一看請求的域名是bdomain.com，便將存放在客戶端的B網站的Cookie給順帶一起發了過去，這樣，服務器就會誤認為是你主動要關注我的，於是，便向數據庫寫入了一條記錄，而你就在不知不覺中，默默無聞的關注我了~~~
這樣，我的目的就達到了~~~~
而如果很多用戶都像你一樣，在登錄B微博的同時查看了我的帖子，那么他們也一樣，默默無聞的關注了我~於是，我的粉絲量就大增！~~~
這里要說明一下：上面例子中說的同時打開多個網頁只是可以被利用的方法中的一種，但並不是唯一的一種，你要知道，黑客們可不是吃素的啊，他們手段多着呢~在此順道向黑客們的技術深深的致一敬~！
四、CSRF原理：
從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個步驟：
1.登錄受信任網站A，並在本地生成Cookie。
2.在不登出A的情況下，訪問危險網站B。
看到這里，你也許會說：“如果我不滿足以上兩個條件中的一個，我就不會受到CSRF的攻擊”。是的，確實如此，但你不能保證以下情況不會發生：
1.你不能保證你登錄了一個網站后，不再打開一個tab頁面並訪問另外的網站。
2.你不能保證你關閉瀏覽器了后，你本地的Cookie立刻過期，你上次的會話已經結束。（事實上，關閉瀏覽器不能結束一個會話，但大多數人都會錯誤的認為關閉瀏覽器就等於退出登錄/結束會話了……）
3.上圖中所謂的攻擊網站，可能是一個存在其他漏洞的可信任的經常被人訪問的網站。
示例1：
銀行網站A，它以GET請求來完成銀行轉賬的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000
危險網站B，它里面有一段HTML的代碼如下：
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
首先，你登錄了銀行網站A，然后訪問危險網站B，噢，這時你會發現你的銀行賬戶少了1000塊......
為什么會這樣呢？原因是銀行網站A違反了HTTP規范，使用GET請求更新資源。在訪問危險網站B的之前，你已經登錄了銀行網站A，而B中的<img>以GET的方式請求第三方資源（這里的第三方就是指銀行網站了，原本這是一個合法的請求，但這里被不法分子利用了），所以你的瀏覽器會帶上你的銀行網站A的Cookie發出Get請求，去獲取資源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”，結果銀行網站服務器收到請求后，認為這是一個更新資源操作（轉賬操作），所以就立刻進行轉賬操作......
示例2：
如果銀行改為POST請求實現轉賬的話，危險網站B的HTML代碼如下：
<form method='POST' action='http://www.cmbchina.com/'>
<input type='text' value='6227000330022376705' name='to' style='display:none'>
<input type='text' value='1000' name='to' style='display:none'>
<a onlick='onsubmit()'><img 美女></a>
</form>
一點美女還是會少1000塊....
五、CSRF防御
POST+隱藏的隨機字符串，隨機字符串是銀行網站發給你的
原理：我以GET方式去訪問轉賬URL會看到轉賬單，在這個頁面里面會有隱藏的一段隨機字符串，會加到我的Cookie里，
我擦，那么問題來了：如果我點擊招商銀行的轉賬頁面，招商銀行會把隨機字符串放到我的Cookie里，這個時候我突然轉到危險網站點了美女圖片，然后他通過Ajax以POST方式發送求請求到銀行，后台也能拿到我的隨機字符串，那不也少錢了