CSRF攻擊原理及預防手段

時間 2019-11-10

標籤 csrf 攻擊原理預防手段欄目系統安全简体版

原文原文鏈接

CSRF全程 Cross Site Request Forgery, 跨站域請求僞造.這種攻擊方式相對於XSS,SQL注入等攻擊方式比較晚被發現,今天就來說解下這種攻擊方式以及避免方式.php

攻擊過程

假設abc用戶登陸銀行的網站進行操做, 同時也訪問了攻擊者預先設置好的網站.html
abc點擊了攻擊者網站的某一個連接,這個連接是http://www.bank.com/xxxx指向銀行,銀行服務器會根據這個連接攜帶的參數會進行轉帳操做.git
銀行服務器在執行轉帳操做以前會進行SESSION驗證是否登陸, 可是因爲abc已經登陸了銀行網站,攻擊者的連接也是www.bank.com.因此攻擊的連接就會攜帶session id到銀行服務器.github
因爲session id是正確的,因此銀行會判斷操做是由本人發起的,執行轉帳操做.數據庫

演示

根據上面的說明,咱們來模擬一下攻擊的過程.瀏覽器

有www.bank.com跟www.hacker.com.用戶abc登陸www.bank.com網站以後點擊了www.hacker.com的點擊抽大獎的誘騙連接安全
此連接會向www.bank.com發起一個post請求.因爲請求域名爲www.bank.com,因此請求會攜帶www.bank.com的session id.服務器

www.hacker.com的代碼

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<form method="post" action="http://www.bank.com/transfer.php">
    <input type="hidden" name="from" value="abc">
    <input type="hidden" name="money" value="10000">
    <input type="hidden" name="to" value="hacker">
    <input type="button" onclick="submit()" value="點擊抽大獎">
</form>
</body>

能夠發現,www.hacker.com的網頁中包含了一個向www.bank.com發起的post請求.而且表單都沒隱藏了,只有一個誘騙用戶點擊的按鈕.cookie

完整的實例代碼能夠在github上找到.傳送門.session

預防

從上面的例子能夠看到csrf攻擊.黑客不能拿到cookie,也沒辦法對服務器返回的內容進行解析.惟一能作的就是給服務器發送請求.經過發送請求改變服務器中的數據.上面的例子中攻擊者誘導用戶點擊連接進行轉帳操做,使得銀行數據庫中受害者的金額發生了改變.

瞭解了csrf攻擊的原理和目標,提出了兩種防護手段

referer 驗證

根據HTTP協議,在http請求頭中包含一個referer的字段,這個字段記錄了該http請求的原地址.一般狀況下,執行轉帳操做的post請求www.bank.com/transfer.php應該是點擊www.bank.com網頁的按鈕來觸發的操做,這個時候轉帳請求的referer應該是www.bank.com.而若是黑客要進行csrf攻擊,只能在本身的網站www.hacker.com上僞造請求.僞造請求的referer是www.hacker.com.因此咱們經過對比post請求的referer是否是www.bank.com就能夠判斷請求是否合法.

這種方式驗證比較簡單,網站開發者只要在post請求以前檢查referer就能夠,可是因爲referer是由瀏覽器提供的.雖然http協議有要求不能篡改referer的值.可是一個網站的安全性絕對不能交由其餘人員來保證.

token 驗證

從上面的樣式能夠發現,攻擊者僞造了轉帳的表單,那麼網站能夠在表單中加入了一個隨機的token來驗證.token隨着其餘請求數據一塊兒被提交到服務器.服務器經過驗證token的值來判斷post請求是否合法.因爲攻擊者沒有辦法獲取到頁面信息,因此它沒有辦法知道token的值.那麼僞造的表單中就沒有該token值.服務器就能夠判斷出這個請求是僞造的.

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。