一 概念html
你這能夠這麼理解CSRF攻擊:攻擊者盜用了你的身份,以你的名義發送惡意請求。CSRF可以作的事情包括:以你名義發送郵件,發消息,盜取你的帳號,甚至於購買商品,虛擬貨幣轉帳......形成的問題包括:我的隱私泄露以及財產安全。web
二 過程後端
1 受害者 Bob 在銀行有一筆存款,經過對銀行的網站發送請求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可使 Bob 把 1000000 的存款轉到 bob2 的帳號下。跨域
2 一般狀況下,該請求發送到網站後,服務器會先驗證該請求是否來自一個合法的 session,而且該 session 的用戶 Bob 已經成功登錄。瀏覽器
3 黑客 Mallory 本身在該銀行也有帳戶,他知道上文中的 URL 能夠把錢進行轉賬操做。Mallory 能夠本身發送一個請求給銀行:http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。緩存
可是這個請求來自 Mallory 而非 Bob,他不能經過安全認證,所以該請求不會起做用。安全
4 這時,Mallory 想到使用 CSRF 的攻擊方式,他先本身作一個網站,在網站中放入以下代碼: src=」http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory 」,而且經過廣告等誘使 Bob 來訪問他的網站。服務器
5 當 Bob 訪問該網站時,上述 url 就會從 Bob 的瀏覽器發向銀行,而這個請求會附帶 Bob 瀏覽器中的 cookie 一塊兒發向銀行服務器。大多數狀況下,該請求會失敗,由於他要求 Bob 的認證信息。cookie
6 可是,若是 Bob 當時恰巧剛訪問他的銀行後不久,他的瀏覽器與銀行網站之間的 session 還沒有過時,瀏覽器的 cookie 之中含有 Bob 的認證信息。session
這時,悲劇發生了,這個 url 請求就會獲得響應,錢將從 Bob 的帳號轉移到 Mallory 的帳號,而 Bob 當時絕不知情。等之後 Bob 發現帳戶錢少了,即便他去銀行查詢日誌,他也只能發現確實有一個來自於他本人的合法請求轉移了資金,沒有任何被攻擊的痕跡。而 Mallory 則能夠拿到錢後逍遙法外。
三 基本過程圖解以下:
四 總結
用戶和網站經過正常登錄,創建了信任關係,在這種信任關係的有效期內,用戶經過廣告等形式進入了攻擊者的網站,攻擊者會在本身的網站內訪問與用戶創建的信任關係的網站的某些敏感操做,而此時,用戶和網站還在信任有效期內。
也能夠經過相似xss的方式,上傳圖片之類的東西,src=某個請求,用戶進入這個網站以後會發送這條請求。
並非只有get請求才能被csrf,攻擊者一樣能夠經過表單完成一次post的csrf攻擊。
五 防護
1. 判斷referer:並很差,
見[花式繞過csrf技巧]
(https://www.ohlinge.cn/web/csrf_referer.html?utm_source=tuicool&utm_medium=referral)。
2. jwt,比較經常使用,後端返回token,localstorage是有跨域限制的,其餘域名沒法訪問信任域的緩存,每次請求在請求上帶上token。