如何用簡潔生動的語言理清XSS和CSRF的區別？
馬三立小品〈逗你玩〉中的小偷就利用xss突破了防盜系統。
防盜系統啟動:
媽媽：給我看著衣服小孩：好的小偷來
正常工作：
小孩：你是誰？小偷：我叫張三小孩：媽媽，有人偷衣服媽媽：誰？小孩：張三小偷被捉漏洞：
小孩：你是誰？小偷：我叫逗你玩
小孩：媽媽，有人偷衣服媽媽：誰？小孩：逗你玩 媽媽：。。。csrf是讓用戶在不知情的情況，冒用其身份發起了一個請求小偷：你媽媽喊你去買洗衣粉----------------------------------------------補充一下，XSS本質是Html注入，和SQL注入差不多。SQL、Html、人類語言都是指令和數據混在一起，都存在注入風險（程序根據分隔符、標籤識別指令和數據，人類則是根據語境、語義和日常經驗判斷）。比如註冊用戶時，用戶輸入「張三」並提交，服務端會生成「 &
歡迎新用戶，張三& 」傳給瀏覽器。如果用戶輸入"& 歡迎新用戶，&
xss：用戶過分信任網站，放任來自瀏覽器地址欄代表的那個網站代碼在自己本地任意執行。如果沒有瀏覽器的安全機制限制，xss代碼可以在用戶瀏覽器為所欲為；csrf：網站過分信任用戶，放任來自所謂通過訪問控制機制的代表合法用戶的請求執行網站的某個特定功能。
xss原理上利用的是瀏覽器可以拼接成任意的javascript，然後黑客拼接好javascript讓瀏覽器自動地給伺服器端發出多個請求（get、post請求）。csrf原理上利用的是網站伺服器端所有參數都是可預先構造的原理，然後黑客拼接好具體請求url，可以引誘你提交他構造好的請求。
CSRF: 服務端程序員的鍋XSS: 服務端 View 層或者客戶端程序員的鍋
xss:攻擊者盜用用戶身份來做事。[盜用身份之後可以做很多事]csrf:攻擊者利用用戶的手來做事。[借用戶的手來做事，做的事有局限性]
一直組織不好語言，感覺這樣說的還是很片面....
今天在研究，小結一下，並一定對，歡迎指正。感覺某種程度上說二者不在一個層面。xss強調的是手法，即如何獲取用戶信息，csrf強調的是效果，即如何進行非法操作。當然利用從xss獲取的用戶信息也可以進行非法操作。流程角度，在二者流程的開頭，有很多相似，即用戶都是點擊危險鏈接，然後，xss是一進（進入被攻擊的伺服器）一出（返回用戶信息到攻擊者指定的地方）再進（比如攻擊者利用被攻擊者的信息登錄被攻擊的伺服器把錢轉給攻擊者）。csrf只有一進（進入被攻擊的伺服器），然後直接破壞（比如把被攻擊用戶的錢轉給攻擊者）而不出。
一個是在飯里下藥，一個是在屎里下毒。前者xss植入惡意代碼後為所欲為，後者csrf在你每次出恭時假傳聖旨聞屎如見人。xss是前端輸出時未按場景嚴謹轉義的結果，csrf是伺服器端行為介面未避開普通資源請求所採用的模式。另外還有一種漏洞你沒提到。叫誘騙點擊攻擊。具體英文名字忘記了。——網友提醒，叫clickjacking。這種很多人不會注意防範。要麼用iframe顯示富文本，要麼過濾富文本樣式中的position fixed並配合一切其他的容器樣式設置。
其實嚴格來說xss中的第一個x，也就是cross只是一種廣義上的跨站，就像矩形是特殊的平行四邊形一樣，準確來說xss應該異譯為javascript注入更加準確。而csrf攻擊只會實施一個請求某資源（介面）的操作，而不會執行黑客所要執行的腳本，這就是區別。
題主估計主要是問反射型XSS和CSRF的異同吧？兩者都是用戶的瀏覽器以用戶的登錄身份訪問了一個鏈接，因此帶來的攻擊，似乎有點類似。而CSRF在於那個鏈接本身做了一件用戶意料之外的事情，反射型XSS在於HTTP返回內容中有剛才鏈接帶過去的攻擊串，變成了JS腳本然後執行了，做了用戶意料之外的事情。所以前者能做的只是那些沒有CSRF保護的URL所能幹的事情。後者能做的就是javascript所能幹的所有事情
一般說 防禦外部請求的csrf有以下幾種措施：referer驗證，token，http請求頭修改，圖片驗證碼。但是如果有個xss進行csrf的話，就可以無視以上所有防禦，甚至是簡單的圖片驗證碼...............................評論說我答非所問，那就正面回答一下。CSRF就是偽造請求，瀏覽器發出了違背用戶意願的請求，例如轉發微博，添加管理員，修改資料等等。外域請求造成的CSRF是漏洞，這是病得治，這個跟XSS沒有任何關係。由XSS引起的CSRF呢，這時XSS是漏洞，CSRF只是作為XSS的payload，但網站本身未必存在csrf漏洞。也就是我上面為什麼說一旦存在xss，csrf的防禦措施都可能失效的原因。
小白來答一下吧，如有不對歡迎指正：
XSS：分為存儲、反射、dom型。是一種代碼注入，瀏覽器沒有智商，你輸入一個&
訪問：www.weibo.com/hehe/deletepage=30userid=10284
好了hehe用戶的id=30號的文章就被刪除掉了，你沒有插入任何惡意代碼，你只是調用了網站本身的js代碼介面，好了你就完成了一次未經授權的刪帖操作，不要問我這個鏈接怎麼來的，我是觀察出來的，這是核心。而且局限性很大，你必須要能訪問到hehe的cookie訪這個url才管用，通俗點說就是hehe在看自己的微博點擊這個鏈接才會生效，這就是上面所說的局限性，CSRF攻擊在實現過程中是非常有條件的，需要在特定條件下，執行特定操作才會觸發
從 COOKIE 的角度說，XSS 是盜取COOKIE 幹壞事，而 CSRF 是借 COOKIE 幹壞事，實質上並沒拿到受害者的 COOKIE。
XSS：城門已破，黑客攜帶各種武器在城內為所欲為
CSRF：城門未破，黑客僅能借用戶的通行令牌進入城內做小偷小摸的事別小看CSRF，如果僅僅在城門外面布防，而忽視城內防禦的話，小偷小摸將會演變成後院起火。xss：我（作為公司內部人員）因為內部監管不嚴混進領導層和領導喝酒打牌csrf：我（偽裝成公司領導）混進領導層里喝酒打牌
xss：有腳本的參與，黑客構造好各種各樣功能的腳本讓你來觸發。
csrf：借你的手觸發某些操作。
XSS是你訪問正常網站的時候，你瀏覽器執行了攻擊者的代碼。有XSS的網站可以直接偽造請求，比CSRF強多了。
CSRF是你點擊了攻擊者提供的鏈接的時候（正常網站或其它有攻擊者代碼的網站），你的瀏覽器向正常網站發送攻擊者期望的請求。這倆也能結合起來，比如A網站有XSS的問題，B網站有CSRF的問題，那麼攻擊者可以在A里插入代碼，當你訪問A的時候，你在B網站上的信息就被盜用了。
從本質上講，XSS是HTML的問題。CSRF是HTTP的問題。XSS是內容沒有過濾導致瀏覽器將攻擊者的輸入當代碼執行。CSRF則是因為瀏覽器在發送HTTP請求的時候會自動帶上cookie，而一般網站的session都存在cookie裡面。
XSS的危害大一些，但是容易解決，伺服器對於任何人的輸入都過濾一下再放到頁面上就行了。解決CSRF則需要瀏覽器的支持，伺服器只能解決http get的csrf，其它的搞不定。瀏覽器可以搞定其它的，http get它搞不定。目前大部分瀏覽器都可以禁止跨域的訪問，還可以禁止javascript讀取cookie。所以網站一般來講把瀏覽器的功能都用上就好了。關鍵還是要在瀏覽器裡面讓攻擊者不能偽裝成受害者發送請求，而不是在伺服器端檢測請求是否是偽造的。多吹兩句，為什麼說伺服器其它的搞不定，因為如果瀏覽器不禁止的話，用iframe加上腳本模擬正常使用者的提交可以欺騙絕大部分的伺服器。就算是驗證碼也沒用，現在的OCR很強的，有個百分之三十或四十的通過率驗證碼就是擺設了，多提交幾次即可。通過率太低的話，人眼識別也高不到哪兒去，影響正常用戶，網站會被噴。另外就算你驗證碼扛住了OCR，人家還可以把你的驗證碼圖片發到自己的伺服器上，人肉識別，這你擋不住。對於大型網站來說，人家多請幾個人來人肉識別，花不了多少錢。所以說，csrf還得瀏覽器支持。伺服器只能提高門檻，擋一擋小白。不過話說回來，驗證是否是本人在操作還可以使用手機簡訊，郵箱啊等等手段，但那樣雖然能防止csrf，但是用戶體驗太差。另外也有絕對不會有csrf的辦法，就是你的網站不用cookie，用一些別的方法記錄session或者session ID，比如自己設置http header，存到localstorage 等等。當然如果瀏覽器把那些信息也泄漏的話那就gg了。XSS：一進一出
最基本的盜取cookie，後續還要自己利用…
CSRF：只進不出精準打擊，進去就實現目的：加管理員賬戶等…一步到位&
XSS 跨站腳本攻擊 Cross-Site Scripting
比如微博昵稱存在XSS漏洞，你把昵稱修改為
Jack&
別人訪問你的微博主頁是http://weibo.com/Jack後，上面的腳本自動執行，自動成為你的粉絲。
CSRF 跨站請求偽造 Cross-site request forgery
比如某網站的轉賬操作是
http://xxx.com/transfer?from=張三to=李四?moeny=100
張三登錄了此網站沒有退出，這時登錄李四的網站後自動跳轉到
http://xxx.com/transfer?from=張三to=李四?moeny=200
李四多轉走了100
看看這個吧總結 XSS 與 CSRF 兩種跨站攻擊
推薦閱讀：