csrf

CSRF（Cross-Site Request Forgery，跨站點偽造請求）是一種網路攻擊方式，該攻擊可以在受害者毫不知情的情況下以受害者名義偽造請求發送給受攻擊站點，從而在未授權的情況下執行在權限保護之下的操作，具有很大的危害性，具體來講，可以這樣理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求，對服務器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作，比如以你的名義發送郵件、發訊息，盜取你的賬號，添加系統管理員，甚至于購買商品、虛擬貨幣轉賬等，

什么是CSRF攻擊

首先用戶C瀏覽并登錄了受信任站點A；

登錄資訊驗證通過以后，站點A會在回傳給瀏覽器的資訊中帶上已登錄的cookie，cookie資訊會在瀏覽器端保存一定時間（根據服務端設定而定）；

完成這一步以后，用戶在沒有登出（清除站點A的cookie）站點A的情況下，訪問惡意站點B；

這時惡意站點 B的某個頁面向站點A發起請求，而這個請求會帶上瀏覽器端所保存的站點A的cookie；

站點A根據請求所帶的cookie，判斷此請求為用戶C所發送的，

因此，站點A會報據用戶C的權限來處理惡意站點B所發起的請求，而這個請求可能以用戶C的身份發送郵件、短信、訊息，以及進行轉賬支付等操作，這樣惡意站點B就達到了偽造用戶C請求站點 A的目的，

受害者只需要做下面兩件事情，攻擊者就能夠完成CSRF攻擊：

登錄受信任站點 A，并在本地生成cookie；

在不登出站點A（清除站點A的cookie）的情況下，訪問惡意站點B，

很多情況下所謂的惡意站點，很有可能是一個存在其他漏洞（如XSS）的受信任且被很多人訪問的站點，這樣，普通用戶可能在不知不覺中便成為了受害者，

實體

假設某銀行網站A以GET請求來發起轉賬操作，轉賬的地址為www.regina.com/transfer.do？accountNum=l000l&money=10000，引數accountNum表示轉賬的賬戶，引數money表示轉賬金額，
而某大型論壇B上，一個惡意用戶上傳了一張圖片，而圖片的地址欄中填的并不是圖片的地址，而是前而所說的轉賬地址：<img src="http://www.regina.com/transfer.do?accountNum=l000l&money=10000">

當你登錄網站A后，沒有及時登出，這時你訪問了論壇B，不幸的事情發生了，你會發現你的賬號里面少了10000塊...

為什么會這樣呢，在你登錄銀行A時，你的瀏覽器端會生成銀行A的cookie，而當你訪問論壇B的時候，頁面上的標簽需要瀏覽器發起一個新的HTTP請求，以獲得圖片資源，當瀏覽器發起請求時，請求的卻是銀行A的轉賬地址www.regina.com/transfer.do?accountNum=l000l&money=10000，并且會帶上銀行A的cookie資訊，結果銀行的服務器收到這個請求后，會以為是你發起的一次轉賬操作，因此你的賬號里邊便少了10000塊，

因此，這種GET請求的方式早已不安全了，通常都會使用POST請求的方式互動，

假設銀行將其轉賬方式改成POST提交，而論壇B恰好又存在一個XSS漏洞，惡意用戶在它的頁面上植入如下代碼：

<form id="aaa" action="http://www.regina.com/transfer.do" method="POST" display="none">
    <input type="text" name="accountNum" value="https://www.cnblogs.com/ivanlee717/p/10001"/>
    <input type="text" name="money" value="https://www.cnblogs.com/ivanlee717/p/10000"/>
</form>
<script>
    var form = document.forms('aaa');
    form.submit();
</script>

如果你此時恰好登錄了銀行A，且沒有登出，當你打開上述頁面后，腳本會將表單aaa提交，把accountNum和money引數傳遞給銀行的轉賬地址http://www.xxx.com/transfer.do，同樣的，銀行以為是你發起的一次轉賬會從你的賬戶中扣除10000塊，

token

token其實就是一個令牌，用于用戶驗證的，token的誕生離不開CSRF，正是由于上面的Cookie/Session的狀態保持方式會出現CSRF，所以才有了token，

token的特點：

無狀態、可擴展
支持移動設備
跨程式呼叫
安全

token的機制：
基于Token的身份驗證的程序如下:

用戶登錄校驗，校驗成功后就回傳Token給客戶端

客戶端收到token后保存在客戶端，token可以保存在Cookies 或 Local Storage 或 Session Storage中，

客戶端每次訪問API是攜帶Token到服務器端

服務器端采用filter過濾器校驗，驗證傳遞的token和演算法生成的token是否一致，校驗成功則回傳請求資料，校驗失敗則回傳錯誤碼

當我們在程式中認證了資訊并取得 token 之后，我們便能通過這個 token 做許多的事情，我們甚至能創建一個基于權限的token傳給第三方應用程式，這些第三方程式能夠獲取到我們的資料（當然只限于該 token 被允許訪問的資料），

一直困擾的一個問題就是，為什么惡意網站不能利用用戶瀏覽器中的token，而能利用Cookie呢？

這是因為，在信任網站的HTML或js中，會向服務器傳遞引數token，不是通過Cookie傳遞的，若惡意網站要偽造用戶的請求，也必須偽造這個token，否則用戶身份驗證不通過，但是，同源策略限制了惡意網站不能拿到信任網站的Cookie內容，只能使用，所以就算是token是存放在Cookie中的，惡意網站也無法提取出Cookie中的token資料進行偽造，也就無法傳遞正確的token給服務器，進而無法成功偽裝成用戶了，
之前我們選擇的方式是注釋掉settings檔案里csrf相關的中間件，但這種方式實際上是關掉了這個安全機制，其實并不是安全的，

<form action="" method="post">
    {% csrf_token %}
    <input type="hidden" name="" value="">
    name  <input type="text">
    pwd   <input type="password">
    <input type="submit">
</form>

這里新加入了一種input型別叫hidden，這一句話里的name和value雖然是空，但是會自動將生成的csrf_token值放進去，然后一并傳給服務器端

這樣做可以實作csrf的驗證，但是如果前后端進行分離，這樣的渲染就不好實作，所以優化操作可以使用ajax請求

<script>
    $.ajax({
        url: "../getToken",
        success:function (res) {
            console.log(res);
        }
    })
</script>

from django.middleware.csrf import get_token

def getToken(request):
    token = get_token(request)
    return HttpResponse(token)

通過這樣的方式我們就可以拿到一個前后端分離，但是依然可以獲取的token值，接下里我們再對token值進行一些使用，

<form action="" method="post">
    name  <input type="text" >
    pwd   <input type="password" >
    <input type="button" value="https://www.cnblogs.com/ivanlee717/p/ajax submit" > {#button本身不帶有任何事件#}
</form>
<script>
    $.ajax({
        url: "../getToken",
        success:function (res) {
            console.log(res);
            localStorage.setItem("token",res);
        }
    })
    
    $(".ajax_button").click(function () {
        $.ajax({
            url: "../login/",
            type: "post",
            data:{
                user: $(".user").val(),
                pwd: $(".pwd").val(),
                csrfmiddlewaretoken:localStorage.getItem("token"),
            },
            success:function (res) {
                console.log(res);
            }
        })
    })
</script>

當在訪問這個頁面的時候，我們把獲取到的token值存到了localStorage里面，然后再進行表單提交的時候，我們再把token值從里面獲取出來，

方式1：放在請求資料中，

$.ajax({
  url: '/csrf_test/',
  method: 'post',
  data: {'name': $('[name="name"]').val(),
         'password': $('[name="password"]').val(),
         'csrfmiddlewaretoken':$('[name="csrfmiddlewaretoken"]').val()           
        },
  success: function (data) {
    console.log('成功了')
    console.log(data)           },
})

方式2：放在請求頭

$.ajax({
            url: '/csrf_test/',
            method: 'post',
            headers:{'X-CSRFToken':'token值'},  // 注意放到引號里面
            data:{}
}

本文來自博客園，作者：ivanlee717，轉載請注明原文鏈接：https://www.cnblogs.com/ivanlee717/p/16866313.html

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/528728.html

標籤：Python

上一篇：重溫Python基礎——數

下一篇：Python工具箱系列(十二)

CSRF和token以及用django實作

csrf

什么是CSRF攻擊

實體

token