1. 程式人生 > >CSRF的原理與防禦 | 你想不想來一次CSRF攻擊?

CSRF的原理與防禦 | 你想不想來一次CSRF攻擊?

CSRF是Cross Site Request Forgery的縮寫,中文翻譯過來是跨站請求偽造。這個漏洞往往能給使用者帶來巨大的損失,CSRF在等保安全檢測中,也是一個非常重要的檢測項。但是在我們的網站中,大部分都沒有做CSRF的防禦,小夥伴們想不想來一次CSRF攻擊,體驗一下做黑客感覺?如果想要做黑客,可要仔細的往下看喲~

CSRF攻擊的原理

要想理解CSRF攻擊的原理,我們從一個經典的案例出發,看看它是如何進行攻擊的。假設你的銀行網站的域名是www.a-bank.com,這個銀行網站提供了一個轉賬的功能,在這個功能頁面中,有一個表單,表單中有兩個輸入框,一個是轉賬金額,另一個是對方賬號,還有一個提交按鈕。當你登入了你的銀行網站,輸入轉賬金額,對方賬號,點選提交按鈕,就會進行轉賬。

當然,現在的銀行網站不會有這麼簡單的轉賬操作了,我們在這裡只是舉一個簡單的例子,讓大家明白CSRF的原理。咱們可以發散思維,聯想到其他類似的操作。

這個轉賬的表單項,如下所示:

<form method="post" action="/transfer">
    <input type="text" name="amount"/>
    <input type="text" name="account"/>
    <input type="submit" value="Transfer"/>
</form>

當我們輸入金額和賬號,點選提交按鈕,表單就會提交,給後端的銀行網站服務傳送請求。請求的內容如下:

POST /transfer HTTP/1.1
Host: www.a-bank.com
Cookie: JSESSIONID=randomid
Content-Type: application/x-www-form-urlencoded

amount=100.00&account=9876

請求成功後,你輸入的轉賬金額100元,將轉賬到9876這個賬戶當中。假如你完成轉賬操作後,並沒有退出登入,而是訪問了一個惡意網站,這時,你的銀行網站www.a-bank.com還是處於登入狀態,而這個惡意網站中,出現了一個帶有”贏錢“字樣的按鈕,這個”贏錢“字樣的按鈕後面是一個form表單,表單如下:

<form method="post" action="https://www.a-bank.com/transfer">
    <input type="hidden" name="amount" value="100.00"/>
    <input type="hidden" name="account" value="黑客的銀行賬戶"/>
    <input type="submit" value="贏錢!"/>
</form>

我們可以看到這個表單中,金額和賬戶都是隱藏的,在網頁上只看到了一個贏錢按鈕。這時,你忍不住衝動,點了一個”贏錢“按鈕,這時,將會發生什麼操作呢?我們仔細看一下上面表單中的action寫的是什麼?action寫的是你的銀行網站的轉賬請求介面。你點了一下贏錢按鈕,在這個不正規的網站中,將會發送https://www.a-bank.com/transfer這個請求,在傳送這個請求的時候,會自動帶上www.a-bank.com的cookie,不要問我為什麼是這樣,這是瀏覽器的標準,標準就是這樣規定的。銀行後臺接到這個請求後,首先要判斷使用者是否登入,由於攜帶了cookie,是登入的,會繼續執行後面的轉賬流程,最後轉賬成功。你點了一下”贏錢“按鈕,自己沒有賺到錢,而是給黑客轉賬了100元。

這就是CSRF攻擊的原理,在其他的網站向你的網站傳送請求,如果你的網站中的使用者沒有退出登入,而傳送的請求又是一些敏感的操作請求,比如:轉賬,那麼將會給你的網站的使用者帶來巨大的損失。

CSRF的防禦

我們知道了CSRF攻擊的原理,就可以做針對性的防禦了。CSRF的防禦可以從兩個方面考慮,一個是後臺介面層做防禦;另一個則是在前端做防禦,這種不同源的請求,不可以帶cookie。

後端防禦CSRF

我們先聊聊後端的防禦,後端防禦主要是區分哪些請求是惡意請求,哪些請求是自己網站的請求。區分惡意請求的方式有很多,在這裡給大家介紹兩種吧。

第一種,CSRF Token的方式。這種方式是在表單頁面生成一個隨機數,這個隨機數一定要後端生成,並且對這個隨機數進行儲存。在前端頁面中,對這個Token表單項進行隱藏。程式碼如下:

<form method="post" action="/transfer">
    <input type="hidden" name="_csrf" value="4bfd1575-3ad1-4d21-96c7-4ef2d9f86721"/>
    <input type="text" name="amount"/>
    <input type="hidden" name="account"/>
    <input type="submit" value="Transfer"/>
</form>

_csrf就是CSRF Token。我們看到他的value是一個UUID,這個UUID是後臺生成的。當用戶點選轉賬按鈕時,會給銀行的後臺傳送請求,請求中包含_csrf引數,如下:

POST /transfer HTTP/1.1
Host: www.a-bank.com
Cookie: JSESSIONID=randomid
Content-Type: application/x-www-form-urlencoded

amount=100.00&account=9876&_csrf=4bfd1575-3ad1-4d21-96c7-4ef2d9f86721

銀行後臺接收到這個請求後,判斷_csrf的值是否存在,如果存在則是自己網站的請求,進行後續的流程;如果不存在,則是惡意網站的請求,直接忽略。

第二種,通過請求頭中的referer欄位判斷請求的來源。每一個傳送給後端的請求,在請求頭中都會包含一個referer欄位,這個欄位標識著請求的來源。如果請求是從銀行網站發出的,這個欄位會是銀行網站轉賬頁的連結,比如:https://www.a-bank.com/transfer-view;如果是從惡意網站發出的,那麼referer欄位一定不會是銀行網站。我們在做後端防禦時,可以先取出每個請求的請求頭中的referer欄位,判斷是不是以自己網站的域名開頭,在咱們的示例中,如果referer欄位是以https://www.a-bank.com/開頭的,則繼續執行轉賬操作;如果不是,則直接忽略掉這個請求。

以上就是後端防禦CSRF攻擊的兩種方式,都需要在後端做特殊的處理。當然也可以在前端做處理,怎麼做呢?我們接著往下看。

前端防禦CSRF

既然CSRF攻擊的危害這麼大,為什麼不能在前端禁止這種請求呢?各大瀏覽器廠商似乎也注意到了這個問題,谷歌提出了same-site cookies概念,same-site cookies 是基於 Chrome 和 Mozilla 開發者花了三年多時間制定的 IETF 標準。它是在原有的Cookie中,新添加了一個SameSite屬性,它標識著在非同源的請求中,是否可以帶上Cookie,它可以設定為3個值,分別為:

  • Strict
  • Lax
  • None

Cookie中的內容為:

POST /transfer HTTP/1.1
Host: www.a-bank.com
Cookie: JSESSIONID=randomid;SameSite=Strict;

Strict是最嚴格的,它完全禁止在跨站情況下,傳送Cookie。只有在自己的網站內部發送請求,才會帶上Cookie。不過這個規則過於嚴格,會影響使用者的體驗。比如在一個網站中有一個連結,這個連結連線到了GitHub上,由於SameSite設定為Strict,跳轉到GitHub後,GitHub總是未登入狀態。

Lax的規則稍稍放寬了些,大部分跨站的請求也不會帶上Cookie,但是一些導航的Get請求會帶上Cookie,如下:

請求型別 示例 Lax情況
連結 <a href="..."></a> 傳送 Cookie
預載入 <link rel="prerender" href="..."/> 傳送 Cookie
GET 表單 <form method="GET" action="..."> 傳送 Cookie
POST 表單 <form method="POST" action="..."> 不傳送
iframe <iframe src="..."></iframe> 不傳送
AJAX $.get("...") 不傳送
Image <img src="..."> 不傳送

上面的表格就是SameSite設定為Lax的時候,Cookie的傳送情況。

None就是關閉SameSite屬性,所有的情況下都發送Cookie。不過SameSite設定None,還要同時設定Cookie的Secure屬性,否則是不生效的。

以上就是在前端通過Cookie的SameSite屬性防禦CSRF攻擊,不過大家在使用SameSite屬性時,要注意瀏覽器是否支援SameSite屬性。

總結

到這裡CSRF的攻和防都已經介紹完了,大部分網站都是沒有做CSRF防禦的,小夥伴們有沒有想當黑客的癮,找幾個網站搞一下試試吧~~

相關推薦

CSRF原理防禦 | 想來CSRF攻擊

CSRF是Cross Site Request Forgery的縮寫,中文翻譯過來是跨站請求偽造。這個漏洞往往能給使用者帶來巨大的損失,CSRF在等保安全檢測中,也是一個非常重要的檢測項。但是在我們的網站中,大部分都沒有做CSRF的防禦,小夥伴們想不想來一次CSRF攻擊,體驗一下做黑客感覺?如果想要做黑客,可

CSRF理解防禦

class 利用 .org 前後端分離 xss 網站攻擊 image 相關 能夠 一、說明 記得以前去面試技術也不太會但你總得講點東西,讓面試時間長一些讓面試官覺得你基礎還可以,當時選的就是名頭比較大的OWASP TOP 10。TOP 10嘛你總得拿出至少三個點來講的細一些

Http-only原理防禦XSS實踐

預備知識 XSS攻擊       Http-only的設計主要是用來防禦XSS攻擊,所以學習本實驗的讀者應首先了解XSS攻擊的相關原理內容。       跨站點指令碼攻擊是困擾Web伺服器安全的常見問題之

php XSS攻擊原理防禦

資料安全是軟體設計中要考慮的問題,在程式中保持資料的安全,除了保證程式碼內部執行的可靠,最主要就是嚴格控制外部資料,秉持一切使用者輸入的都是不可靠的原則,做好資料的驗證和過濾. PHP最簡單的過濾機制就是轉義,對使用者的輸入和輸出進行轉義和過濾. 我們先搞一

(轉)清華博士王垠的退學申請——研究生,無論搞研究,都該讀讀這篇文章。

我覺得再沒有從實際出發的目標,我的研究就會完全變成紙張了,就像我高中感覺到的一樣。所以後來我就自己設立了一個研究方向,我把自己稱為“研 究博士生”,我要去了解博士生都是怎麼樣生活的。我就想知道有多少學生有跟我類似的困境。我跟很多朋友談過,去了解他們的苦衷,研究生也有,本科的也有。我覺得我還應該瞭解更多的人,就

Qt的訊號可能知道的那些

說到訊號與槽,這是Qt獨有的特點。 1、應該知道的: 一般用訊號和槽都會用到:signals和slots Qt4用法:     connect(sender, SIGNAL(signal), rece

【牛九心得:第3期】也成為富人?

ont 好書 成長 ebp 時間 -c tar 幫助 -o (本文閱讀時間約3分鐘,老師每天都會把自己的心得分享給大家,文章都是自己一字一字親手打出來的,希望能幫助到大家) 大家好,我是牛九老師,接下來和大家一起討論一下,如何能成為富人?

可能知道 款非常牛的國產6AT變速箱要上市了

上海車展 技術發展 設定 並且 執行 但是 最大 很大的 華納 中國汽車產業尤其是汽車零部件產業已經進入“深度國產替代”的新階段,由此前的整車裝配、內外飾基礎零件、核心零件合資模式過渡到高壁壘核心零部件的深度國產化,國內自主廠商渠道外資或合資企業。 變速器是汽車動力總成的

從Paxos到Zookeeper分散式一致性原理實踐 讀書筆記之() 分散式架構

1.1 從集中式到分散式  1 集中式特點  結構簡單,無需考慮對多個節點的部署和節點之間的協作。  2  分散式特點 分不性:在時間可空間上隨意分佈,機器的分佈情況隨時變動 對等性:計算機之間沒有主從之分,所有計算機之間是對等的。副本是分散式系統對資料

隻被“圈養的雞”?

圈養的雞,下蛋多?還是放養的雞,下蛋多? 圈養的雞下的蛋好吃,還是放養的雞下的蛋好吃? 散養雞好處: 1.雞活動空間大,雞活潑,羽毛比圈養雞有光澤,肉味也比圈養雞鮮嫩。 2.減少飼料消耗,可以降低餵養成本。 3.因為活動空間大了,雞的糞便密集度降低了,減少養雞的汙

走進二進制-APT攻擊分析

uac dga name threading 自動 記錄 convert i春秋 nal 原文:https://osandamalith.com/2017/06/04/apt-attack-in-bangladesh/ 由prison翻譯整理,首發i春秋 引言;

DDOS攻擊防禦實錄

前言     筆者所在單位是一家小型創業公司,目前產品正在成長階段,日活躍使用者只有區區幾萬人次,併發只有日均 85/QPS,自建機房,頻寬 100MB。在這樣的背景下,完全沒想過一個小產品會招來黑客的光顧,而且一來就是好幾天。 起因     事情的起因來源於某個愜意的下午,從市場接收到客戶反饋,部分地

九四那麼可怕,我卻還再經歷!

  前天是九四週年慶,很多幣友都在紛紛發文紀念,經歷過的老韭菜在訴說當時的跌宕起伏,隱約有點吹牛逼的味道,沒經歷過的新韭菜也在想象著當時的血雨腥風,好像既是慶幸又有遺憾。   與大家激動的情緒形成鮮明對比的是平靜的市場,本以為在這一天,莊家們也會有所表示,暴力砸盤或者暴力拉盤,總之是把市場

26歲了,再衝動,轉行學程式設計(WEB開發)

26的歲數確實已經不小了,按說應該踏踏實實的做好自己的相關工作了。但是真的不喜歡現在的工作,確切的說是現在的工作性質,在這樣的單位裡工作感覺與世隔絕都差不多了。真心的不想這樣下去了,聽到同學轉行學了WEB開發聽他說還不錯,希望學過的或者在學的能給點建意或者分享一

YOLOv3 訓練自己的資料(解決網上提供的文章成功的問題)

0. 寫本部落格的目的 對於使用yolov3訓練自己的資料,網上雖然文章多,但是經過實驗發現,基本沒有能一次執行的成功的。因此特寫此文,記錄自己在使用yolov3訓練自己的資料時遇到的坑。 環境:ubuntu14 + CUDA8.0 + cudnn5.0  + GTX10

.net core 和 WPF 開發升訊威線上客服營銷系統:(插曲)攻擊行為的分析應對

本系列文章詳細介紹使用 .net core 和 WPF 開發 升訊威線上客服與營銷系統 的過程。本產品已經成熟穩定並投入商用。 線上演示環境:[https://kf.shengxunwei.com](https://kf.shengxunwei.com) 注意:演示環境僅供演示交流與評估,不保證 7x24 小

CSRF攻擊防禦原理

請求偽造 dom pos csrf put ... 服務 功能 問題 CSRF是什麽? (Cross Site Request Forgery, 跨站域請求偽造)是一種網絡的攻擊方式,它在 2007 年曾被列為互聯網 20 大安全隱患之一,也被稱為“One Click A

顛覆認知!A股“金色兩點半”效應一樣

引言 A股中一直流傳著所謂的“兩點半”效應,其中一種說法是,兩點半之後,股市經過了一天的搏殺,走勢逐漸明顯,個股尾盤半小時的走勢大概率會延續到第二天。因此有投資者總結出,選擇在收盤前買入尾盤拉昇的股票,在第二天擇機賣出,可以持續獲得穩定收益。 聽起來,這種說法似乎有一定的道理,但事實是否真的

CSRF攻擊防禦(寫得非常好)

得到 cookie信息 req ret 沒有 不同的 sof 協議 表單 轉載地址:http://www.phpddt.com/reprint/csrf.html CSRF概念:CSRF跨站點請求偽造(Cross—Site Request Forger

CSRF攻擊防禦

動態 開發 開關 如何 1、簡介  CSRF的全名為Cross-site request forgery,它的中文名為 跨站請求偽造(偽造跨站請求【這樣讀順口一點】)  CSRF是一種夾持用戶在已經登陸的web應用程序上執行非本意的操作的攻擊方式。相比於XSS,CSRF是利用了系統對頁面瀏覽器