大家對於這2個攻擊可能比較混淆，因為從名字上就很容易混淆，csrf跨站點偽裝請求和xss跨站點攻擊。我一開始也對這兩個東西搞混淆了，后面發現他們的最根本區別。
（1）CSRF攻擊的主要目的是讓用戶在不知情的情況下攻擊自己已登錄的一個系統，類似於釣魚。如用戶當前已經登錄了郵箱，或bbs，同時用戶又在使用另外一個，已經被你控制的站點，我們姑且叫它釣魚網站。這個網站上面可能因為某個圖片吸引你，你去點擊一下，此時可能就會觸發一個js的點擊事件，構造一個bbs發帖的請求，去往你的bbs發帖，由於當前你的瀏覽器狀態已經是登陸狀態，所以session登陸cookie信息都會跟正常的請求一樣，純天然的利用當前的登陸狀態，讓用戶在不知情的情況下，幫你發帖或干其他事情。預防措施，請求中加入隨機數，讓釣魚網站無法正常偽造請求。
CSRF成功的前提用戶必須登錄到目標站點，且用戶瀏覽了攻擊者控制的站點。
與XSS最為不同一點是CSRF可以不用JS就能達到目的（GET和POST的區別）。
而且攻擊者僅僅只需要給目標站一個請求就能成功。如0X01所說請求可以繞過同源策略。
還有一個天然條件是瀏覽器的安全缺陷：
瀏覽器在最初加入Cookie功能時並沒有考慮安全因素。假設一個網站使用了Cookie，當一個用戶完成身份驗證之后.瀏覽器得到一個標識用戶身份的Cookie，只要不退出或關閉瀏覽器。以后訪問相同網站下的頁面的時候，對每一個請求瀏覽器都會“智能”地主動附帶上該網站的Cookie來標識自己，用戶不需要重新認證就可以被網站識別。當第三方WEB頁面產生了指向當前網站域下的請求時，該請求也會帶上當前網站的Cookie。這種認證方式，稱之為隱式認證。
除了Cookie認證方式之外，其他Web認證機制也面臨同樣的問題。比如HTTP基本認證，用戶通過認證后。瀏覽器仍會“智能”地把用戶名和口令附加到之后第三方發給站點的請求中。即使網站使用了安全套接字(SSL)來加密連接.瀏覽器也會”智能“地自動把SSL認證信息加到第三方發給站點的請求中。
（2）XSS攻擊的主要目的則是，想辦法獲取目標攻擊網站的cookie，因為有了cookie相當於有了seesion，有了這些信息就可以在任意能接進互聯網的pc登陸該網站，並以其他人的生份登陸，做一些破壞。預防措施，防止下發界面顯示html標簽，把</>等符號轉義。
注：
（1）同源策略
同源策略不需要講了，這里只提與CSRF，XSS有關的一個概念：
同源策略僅僅阻止了腳本讀取來自其他站點的內容和阻住對請求的響應。但是卻沒有防止腳本向其他站點發出請求。
請求的內容相當於一個靈魂，沒有肉體，而站點相當於一棟房子。
房子的大門(同源策略）並不會排斥靈魂的進入（靈魂是可以穿牆的嘛）,會排斥非此房子不懷好意的人(其他域的javascript)進入
因而房子里面的主人(程序）對靈魂是視而不見的，或者說是看不見的。且不會理會調皮的請求的。
（2）為什么要用XSS
網上很多文章都是直接講XSS分什么類型，怎樣利用XSS，怎樣發現XSS。好像沒有講為什么要用XSS（可能我閱讀面不太廣），那么不管了，自己總結下。
有人會問：把保存型XSS放在一邊不談，為什要用反射型XSS和DOM-BASE XSS，這么麻煩，不如要攻擊A站點，直接在攻擊者控制的B站點保存一段惡意js，並向用戶傳送一個直接指向這段腳本的鏈接？
原因一：偽裝。攻擊者傳送的是以A站點開頭的URL，而不是B站點開頭的URL更能令用戶上當
比如：A:的站點為：http://www.yunsec.com/
B的站點為：http://www.yunsec.net/
那么你構造URL:http://www.yunsec.net/hello.asp?message=http://www.yunsec.net/evil.js /*http://www.yunsec.net/evil.js為其他域的腳本*/
比直接構造URL：http://www.yunsec.net/evil.js 傳送給用戶，更能讓用戶點擊。
更者，message后面的網址還可以經過編碼，更會迷惑用戶。這種更多用於釣魚。
原因二：第二點也是最重要的一點，由於同源策略的限制，導致如果不用XSS，瀏覽器不會執行腳本或者不會返回攻擊者想要的數據。
利用XSS之所以成功是因為攻擊者的惡意JS是由http://www.yunsec.net/hello.asp提交的。
瀏覽器誤以為是www.yunsec.net此域提交的。
於是瀏覽器會執行http://www.yunsec.net/evil.js這段惡意腳本。
又來YY下下列場景:
A站點相當於藍軍的制造廠（無攻擊性），B站點相當於綠軍的根據地（有攻擊性）
某時，綠軍派遣特工（惡意js）去制造廠竊取機密，但是藍軍的制造廠大門(同源策略)是緊閉的，特工無法穿越（因為不是請求），
但是特工經過高超的裝扮技術（XSS），假扮成了制造廠里的一員,於是大門向特工打開(bypass同源策略)，然后特工達成目的。
（3）CSRF與XSS
剛開始看的時候有個誤區，認為CSRF是一次性的，不會造成worm，后來才知道我當時太天真了，但是CSRF應該是單向的。
CSRF成功的前提用戶必須登錄到目標站點，且用戶瀏覽了攻擊者控制的站點。
與XSS最為不同一點是CSRF可以不用JS就能達到目的（GET和POST的區別）。
而且攻擊者僅僅只需要給目標站一個請求就能成功。如0X01所說請求可以繞過同源策略。
還有一個天然條件是瀏覽器的安全缺陷：
瀏覽器在最初加入Cookie功能時並沒有考慮安全因素。假設一個網站使用了Cookie，當一個用戶完成身份驗證之后.瀏覽器得到一個標識用戶身份的Cookie，只要不退出或關閉瀏覽器。以后訪問相同網站下的頁面的時候，對每一個請求瀏覽器都會“智能”地主動附帶上該網站的Cookie來標識自己，用戶不需要重新認證就可以被網站識別。當第三方WEB頁面產生了指向當前網站域下的請求時，該請求也會帶上當前網站的Cookie。這種認證方式，稱之為隱式認證。
除了Cookie認證方式之外，其他Web認證機制也面臨同樣的問題。比如HTTP基本認證，用戶通過認證后。瀏覽器仍會“智能”地把用戶名和口令附加到之后第三方發給站點的請求中。即使網站使用了安全套接字(SSL)來加密連接.瀏覽器也會”智能“地自動把SSL認證信息加到第三方發給站點的請求中。
因此第三方請求相當於無肉體的靈魂，雖然可以進入房子，但是只能四處飄盪毫無作為。
然而當靈魂遇到了自動附加上的肉體(cookie)就會變身組成一個完整的人，而且是通過了房子認證的人，屬於房子的一部分。
那么靈魂一旦復活，就開始暴漏本性，執行惡意行為，雖然只能在房子里橫，但是足以造成混亂。(如添加管理員，發表欺騙性狀態等等)。
下圖就是人人網爆出的一個CSRF利用頁面代碼,人人網的CSRF應該是屢見不鮮了，幾乎每次搞個活動都會爆出吧。
| 腳本頁面http://bookman.sinaapp.com/doover.php，訪問該頁面后會發送一條狀態“已經結束了，這是我的自白，想明白原理的看我日志就好。http://bookman.sinaapp.com/doover.php” |
由圖可以看出CSRF的代碼是在第三方站點就可以執行了，所以說即使有對輸入的檢查，CSRF一樣都可以繞過，所以一個應用程序如果有XSS漏洞，那么極大可能會有CSRF漏洞，但是一個應用程序沒有XSS漏洞，並不能代表沒有CSRF漏洞。