資訊專欄INFORMATION COLUMN
摘要：了解了攻擊者利用的一些原理，就對應的可以找到一些對應措施在服務端驗證的字段。因此，從某些方面來說，是相對安全的。個人覺得相對安全的做法就是既驗證，同時也校驗。整個過程雖然比較難，但這讓自己對于有了更深刻的認識。
CSRF
CSRF（Cross Site Request Forgery, 跨站域請求偽造）的定義，相信大家都不陌生。它是指攻擊者通過誘導用戶，打開已精心設計好的頁面后，發送請求到某個網站執行某個操作(修改數據)的過程。這里有以下三個前提：
1、用戶已登錄某可信網站(A站，以下所提到的A站都指這里的某可信網站)
2、A站存在某個請求，可以修改或保存信息(例如：/saveinfo)
3、用戶在A站Session過期前打開攻擊者設計好的的頁面，并自動或觸發發送請求(/saveinfo)
看起來要求聽苛刻的，但的確存在這種情況。“即便是大名鼎鼎的 Gmail, 在 2007 年底也存在著 CSRF 漏洞，從而被黑客攻擊而使 Gmail 的用戶造成巨大的損失。”
想要了解怎么應對CSRF，先來看看攻擊者干些什么。
攻擊者能干什么因為受同源策略限制，攻擊者并不能拿到A站的任何信息（Cookies）和響應信息，他只能利用發送請求時，會帶上cookies去校驗登錄信息或權限的特性，去修改用戶的數據，來達到攻擊目的。因此，一般用于獲取信息而不涉及到修改信息的請求(Get)就不用擔心會有CSRF危險了，重要的是能修改信息的請求。當然，如果你用Get去修改信息，那就需要考慮防范CSRF了。but這樣做本身就違背了HTTP method設定的初衷，同時Get的攻擊方式更為簡單，一個Img標簽加上JavaScript就能觸發。所以不建議這么做
CRSF預防措施正所謂兵來將擋，水來土掩。了解了攻擊者利用的一些原理，就對應的可以找到一些對應措施
1、在服務端驗證HTTP的Referer字段。
此方法成本較小，只需要在服務端攔截請求，判斷Referer是否來自于同一域名，如果不是或者不存在CSRF的話，則認為有可能是CSRF攻擊，直接過濾。但這種方法也有弊端，那就是當有些人會擔心Referer會泄露個人信息時（畢竟像服務器發送了自己的來源地址）。這些人會嘗試去關閉Referer。這樣當這些用戶發起請求時就不會帶上Referer，這個請求就會被判成有可能的CSRF攻擊，因為按照上述過濾規則，請求頭中無Referer的有可能會是CSRF攻擊。
2、在請求地址中添加 token 并驗證
此方法的核心思想就是，構造成什么樣的信息，來辨別請求是從用戶手中發出，還是被攻擊者利用而發出的，很顯然Cookie不能做到，因為用戶和攻擊者都能將同樣的Cookie帶到服務器上。
答案就是token(令牌)，它由服務端通過一定算法生成，每當用戶請求頁面的時候，則向用戶返回的頁面中帶上一個全新的token。下次用戶在發送請求的時候，就帶上該token與服務器的token進行對比。但這token要放在哪里呢？
三種情況：
1 對于Get請求，在Url后面動態加上token。 此方法也有一定約束，頁面有很多鏈接，一個一個加太麻煩，就需要在document加載完以后，通過js來輔助完成了。但這個方法對于動態生成的內容，就無能為力了。
2 Post請求 在form表帶中加上
< input type=”hidden” name=token value=”tokenvalue”/>
（查看PC淘寶的個人中心，其修改資料就是用的此方法）由于同源策略，攻擊者是拿不到表單里的數據的。此方法也跟Get請求有同樣的問題，那就是對于多鏈接和動態生成的內容，js批量加上token的辦法就不行了，只能手動添加。
3、對于Ajax請求，如果跨域，則默認不會帶上A站的cookie。因此，從某些方面來說，是相對安全的。但是根據w3c對Ajax的一個屬性的描述
4.6.4 The withCredentials attribute
client . withCredentials
True when user credentials are to be included in a cross-origin request. False when they are to be excluded in a cross-origin request and when cookies are to be ignored in its response. Initially false.
大概說的意思是，如果withCredentials為true，則存在跨域請求的時候，用戶的credentials(包括cookie，我是這么理解的，如有錯歡迎指正)會被帶上。
如果將withCredentials設為true，這樣也會存在上述的安全問題，因為Cookies在發送請求的同時也被戴上了。
總結1、攻擊者是利用用戶登錄過信任網站后，在會話未過期之前誘導用戶打開有問題的網站而達到攻擊目的的
2、常見的防御措施有校驗請求頭的referer，以及新增攻擊者無法獲取的隨機數token(令牌)來達到防御目的的。
3、token存放的地方有多種，對于POST請求，則構造hideen的input標簽；對于Get則在鏈接后添加token；對于ajax，則在cookie中添加token。
4、個人覺得相對安全的做法就是既驗證referer，同時也校驗token。如涉及到更隱秘的操作，則需要通過驗證碼或者手動輸入密碼來做防范了。
參考文章：
https://www.w3.org/TR/2014/WD...
https://www.ibm.com/developer...
https://en.wikipedia.org/wiki...
第一次寫Post，過程如此之多，小到markdown語法；大到發現問題、探索分析問題、查閱資料并自測驗證。最后通篇檢查，是否存在有問題的地方。整個過程雖然比較難，但這讓自己對于CRSF有了更深刻的認識。在團隊完成分享后不遺余力整理的一篇，相信以后會更好。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/11291.html
摘要：關于循環和閉包當循環和閉包結合在一起時，經常會產生讓初學者覺得匪夷所思的問題。閉包是一把雙刃劍是比較難以理解和掌握的部分，它十分強大，卻也有很大的缺陷，如何使用它完全取決于你自己。 在談閉包之前，我們首先要了解幾個概念： 什么是函數表達式？ 與函數聲明有何不同？ JavaScript查找標識符的機制 JavaScript的作用域是詞法作用域 JavaScript的垃圾回收機制 先來...
摘要：使用的方法假設要在和頁面之間傳遞數據頁面頁面參考鏈接下面談一下跨域訪問的一些安全性問題，主要是和攻擊問題。在跨域訪問中，注入主要是參數注入，如防止措施是對參數進行校驗過濾。 所謂跨域，或者異源，是指主機名（域名）、協議、端口號只要有其一不同，就為不同的域（或源）。瀏覽器中有一個基本的策略，叫同源策略，即限制源自A的腳本只能操作同源頁面的DOM。 先聊一下w3c的CORS規范：CORS旨...
摘要：安全問題的分類按照所發生的區域分類后端安全問題所有發生在后端服務器應用服務當中的安全問題前端安全問題所有發生在瀏覽器單頁面應用頁面當中的安全問題按照團隊中哪個角色最適合來修復安全問題分類后端安全問題針對這個安全問題，后端最適合來修復前端安全 安全問題的分類 按照所發生的區域分類 后端安全問題：所有發生在后端服務器、應用、服務當中的安全問題 前端安全問題：所有發生在瀏覽器、單頁面應用、...
閱讀 1166·2021-11-22 15:22
閱讀 3837·2021-10-19 13:13
閱讀 3570·2021-10-08 10:05
閱讀 3292·2021-09-26 10:20
閱讀 2984·2019-08-29 14:21
閱讀 2192·2019-08-27 10:55
閱讀 1871·2019-08-26 10:31
閱讀 2578·2019-08-23 16:47
