資訊專欄INFORMATION COLUMN
摘要：小明是這個商城的一個用戶，已經(jīng)通過了認(rèn)證，并且是通過實(shí)現(xiàn)認(rèn)證的。瀏覽器就會自動在這個請求上加上之前認(rèn)證過的，而服務(wù)端是通過這個驗(yàn)證是否本人操作的，這樣黑客就在小明完全不知情的情況下就得到了這個訂單的詳情。
昨天晚上偶然看到csrf這個問題，所以就去了解了一下csrf到底是個什么東西。
百度定義：
CSRF（Cross-site request forgery）跨站請求偽造，也被稱為“One Click Attack”或者Session Riding，通?？s寫為CSRF或者XSRF，是一種對網(wǎng)站的惡意利用。盡管聽起來像跨站腳本（XSS），但它與XSS非常不同，XSS利用站點(diǎn)內(nèi)的信任用戶，而CSRF則通過偽裝成受信任用戶的請求來利用受信任的網(wǎng)站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進(jìn)行防范的資源也相當(dāng)稀少）和難以防范，所以被認(rèn)為比XSS更具危險性
一個簡單的例子：
某網(wǎng)上商城獲取一個訂單詳情的接口是127.0.0.1/orders/orderId，并且需要認(rèn)證過后才能訪問這個接口 口。小明是這個商城的一個用戶，已經(jīng)通過了認(rèn)證，并且是通過cookie實(shí)現(xiàn)認(rèn)證的?，F(xiàn)在一個黑客也想要訪問小 明在商城中某個訂單的詳情，他該怎么做呢？很簡單，只要在某個地方發(fā)布一個鏈接地址是 127.0.0.1/orders/orderId這個接口，誘使小明去點(diǎn)擊這個鏈接發(fā)送請求。瀏覽器就會自動在這個請求上加上 之前認(rèn)證過的cookie，而服務(wù)端是通過這個cookie驗(yàn)證是否本人操作的，這樣黑客就在小明完全不知情的情況下 就得到了這個訂單的詳情。這個接口的操作如果是 購買一個商品，刪除郵件的話，后果將非?？膳?。
為什么會出現(xiàn)上面這種情況呢？
因?yàn)閏ookie是在向這個網(wǎng)頁發(fā)送請求時自動攜帶的，而我昨天困擾的問題就是為什么token會比cookie安全。 原因其實(shí)就是token一般存在sessionStorage或localStorage中，而它不能在本站點(diǎn)之外的其他站點(diǎn)獲取 到，所以就算你在別處點(diǎn)擊了一個包含這個接口的鏈接也不會導(dǎo)致token泄露。
如何防范csrf攻擊？
1.盡量使用POST，限制GET
post相對get來說更安全，但是還是能在鏈接中嵌套一個表單然后提交
2.設(shè)置瀏覽器cookie策略
禁止在第三方網(wǎng)站上使用cookie
3.加驗(yàn)證碼
每次發(fā)送重要請求都通過驗(yàn)證碼和服務(wù)端進(jìn)行認(rèn)證，這也非常安全，但是用戶體驗(yàn)不好，重要的操作可以這也，但你不能關(guān)注一個用戶或者發(fā)布一個帖子也需要認(rèn)證一次吧。
4.增加referer請求頭檢查
referer請求頭的值就是請求來源的地方，服務(wù)端可以通過判斷這個來源去分辨是否時csrf攻擊，但是一些黑客還是能通過一些技術(shù)很容易的去更改這個請求頭的值
5.使用token
這是最普遍的方法，每次發(fā)送請求都攜帶這個token，它與cookie不同的是，token可以是無狀態(tài)的，即服務(wù)端可以不用保存關(guān)于token的值，而是每次通過計(jì)算驗(yàn)證這個token來判斷是否是當(dāng)前用戶。
黑客還有沒有其他方法能獲取到小明訂單的詳情？
是可以的。黑客可以在商城一個商品的評價下面寫入一個js腳本并且通過圖片偽裝起來，只要小明查看了這個評價，這個js腳本就會自動加載，黑客就可以通過這個js腳本去獲取token值并且發(fā)送請求，因?yàn)楫?dāng)前js腳本是在本站內(nèi)執(zhí)行的，所以是可以訪問到token。上面這個攻擊方式就是xss，通過在用戶訪問的頁面嵌入js代碼使用戶或服務(wù)端受到攻擊。
其實(shí)xss就是csrf的一種實(shí)現(xiàn)方式，xss的防范比較困難，因?yàn)楹诳涂梢酝ㄟ^很多方法在網(wǎng)頁中插入js或html代碼?？梢酝ㄟ^在cookie中設(shè)置了HttpOnly屬性，那么通過js腳本將無法讀取到cookie信息，這樣能有效的防止XSS攻擊。而關(guān)于xss防范又是另一個話題了.....
可以簡單理解為csrf是讓用戶在不知情的情況，冒用其身份發(fā)起了一個請求，而xxs就是通過在網(wǎng)頁上插入js或html代碼發(fā)動攻擊
寫的比較亂，就是token和cookie這里沒有理解透導(dǎo)致這么久才搞懂這個問題。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/103604.html
摘要：何方神圣中文名字是跨站請求偽造，做的事情就是在別的網(wǎng)站，以你的名義對你登陸認(rèn)證過的網(wǎng)站搞事情。中文名字是跨站腳本，做的事情就是在有漏洞的網(wǎng)站，寫個攻擊，或者存?zhèn)€另類的數(shù)據(jù)到網(wǎng)站數(shù)據(jù)庫，對使用網(wǎng)站的用戶造成困擾，屬于站內(nèi)攻擊。 CSRF、XSS何方神圣 CSRF(Cross-site request forgery) 中文名字是跨站請求偽造，做的事情就是在別的網(wǎng)站，以你的名義對你登陸認(rèn) ...
摘要：競賽平臺項(xiàng)目中期總結(jié)軟件謝運(yùn)帷我們小組的選題是大學(xué)生競賽平臺項(xiàng)目，經(jīng)過我們需求分析，原型設(shè)計(jì)等等步驟，我們終于要開始著手實(shí)現(xiàn)這一個龐大的競賽平臺項(xiàng)目。 Cesar競賽平臺項(xiàng)目中期總結(jié) 軟件51 謝運(yùn)帷 2015013185 我們小組的選題是大學(xué)生競賽平臺項(xiàng)目，經(jīng)過我們需求分析，原型設(shè)計(jì)等等步驟，我們終于要開始著手實(shí)現(xiàn)這一個龐大的競賽平臺項(xiàng)目。我們使用Django+mysql處理后端邏輯...
摘要：在谷歌不是這樣，谷歌不會把特定的應(yīng)用裝在某臺服務(wù)器上，業(yè)務(wù)應(yīng)用和服務(wù)器的強(qiáng)綁定對于谷歌這種量級的數(shù)據(jù)中心的維護(hù)難度太高了。但是金融機(jī)構(gòu)的數(shù)據(jù)中心規(guī)模不像谷歌這么大，所以能做到業(yè)務(wù)應(yīng)用和硬件的強(qiáng)綁定。 復(fù)雜的基礎(chǔ)IT架構(gòu)是傳統(tǒng)金融的現(xiàn)狀，如何快速響應(yīng)用戶需求，加快新業(yè)務(wù)上線速度，縮短產(chǎn)品的迭代周期? 數(shù)人云在容器落地金融云的2年實(shí)踐中，實(shí)現(xiàn)金融核心業(yè)務(wù)技術(shù)WebLogic、J2EE、Or...
閱讀 3480·2021-11-22 12:00
閱讀 702·2019-08-29 13:24
閱讀 2938·2019-08-29 11:31
閱讀 2633·2019-08-26 14:00
閱讀 3230·2019-08-26 11:42
閱讀 2507·2019-08-23 18:31
閱讀 830·2019-08-23 18:27
閱讀 2878·2019-08-23 16:58
