bl双性强迫侵犯h_国产在线观看人成激情视频_蜜芽188_被诱拐的少孩全彩啪啪漫画

Web安全中的CSRF代碼審計是怎樣的

這篇文章給大家介紹Web安全中的CSRF代碼審計是怎樣的，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

忻城網站制作公司哪家好，找創新互聯公司！從網頁設計、網站建設、微信開發、APP開發、響應式網站建設等網站項目制作，到程序開發，運營維護。創新互聯公司于2013年創立到現在10年的時間，我們擁有了豐富的建站經驗和運維經驗，來保證我們的工作的順利進行。專注于網站建設就選創新互聯公司。

漏洞介紹

跨站請求攻擊，簡單地說，是攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經認證過的網站并執行一些操作（如發郵件，發消息，甚至財產操作如轉賬和購買商品）。由于瀏覽器曾經認證過，所以被訪問的網站會認為是真正的用戶操作而去執行。這利用了web中用戶身份驗證的一個漏洞：簡單的身份驗證只能保證請求發自某個用戶的瀏覽器，卻不能保證請求本身是用戶自愿發出的

P.S：XSS與CSRF的區別：

XSS：    XSS漏洞——構造payload——發送給受害人——受害人點擊打開——攻擊者獲取受害人的cookie——攻擊者使用受害人cookie完成攻擊

CSRF：  CSRF漏洞——構造payload——發送給受害人——受害人點擊打開——受害人執行代碼——受害人完成攻擊（不知情）

攻擊流程圖：

Web安全中的CSRF代碼審計是怎樣的

從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個步驟：

1.登錄受信任網站A，并在本地生成Cookie。

2.在不登出A的情況下，訪問危險網站B

如果我不滿足以上兩個條件中的一個，我就不會受到CSRF的攻擊。是的，確實如此，但你不能保證以下情況不會發生，畢竟之前說了csrf是在不知情的情況下

1.你不能保證你登錄了一個網站后，不再打開一個tab頁面并訪問另外的網站

2.你不能保證你關閉瀏覽器了后，你本地的Cookie立刻過期，你上次的會話已經結束

所以 CSRF 是一種較難防御、又危險極大的漏洞

原理（CSRF實例）

當我們打開或者登陸某個網站的時候，瀏覽器與網站所存放的服務器將會產生一個會話(cookies)，在這個會話沒有結束時，你就可以利用你的權限對網站進行操作。然而，攻擊者就是利用這個特性，讓受害者觸發我們構造的表單或者語句，然后達到攻擊者想要達到的目的

我們先解釋下：變量 $XssReflex 獲取 get 方式傳遞的變量名為 input 的變量值（值為一個字符串），然后直接通過echo()函數輸出，注意這中間并未對用戶輸入進行任何過濾

建議同學們多花點時間思考一下CSRF攻擊和XSS攻擊原理上的區別，對比著學習會更加容易理解

我在本地搭建了一個實驗環境，模擬了一個網站后臺登錄

Web安全中的CSRF代碼審計是怎樣的

并且密碼和用戶都是admin

Web安全中的CSRF代碼審計是怎樣的

一般來說后臺管理員都具有添加用戶的功能，所以登錄成功之后點擊添加用戶（這里為了方便演示，并沒有讓管理員自定義賬戶名、密碼的功能，而是添加默認的賬戶和密碼）

Web安全中的CSRF代碼審計是怎樣的這里有個添加用戶，我們給他添加下

Web安全中的CSRF代碼審計是怎樣的頁面空白已經添加，我們現在查看下：

Web安全中的CSRF代碼審計是怎樣的這時候如果我們記錄下剛剛添加用戶的網頁地址，是否無論是哪個用戶，只要訪問這個地址就能添加用戶呢？為了驗證這個想法，接下來我們點擊注銷登錄(清楚cookie信息)

Web安全中的CSRF代碼審計是怎樣的

嘗試在瀏覽器輸入之前添加用戶的頁面地址：www.csrf.cn/csrf/adduser.php，嘗試直接添加用戶，沒成功，它直接跳回之前的登錄頁面了

為什么呢？因為adduser.php頁面需要驗證session信息才能執行相應操作。 所以就有人想到：“既然我們自己不能成功訪問這個頁面，能否在管理員不知道的情況下，欺騙他訪問這個頁面呢？”。 我們再次使用admin用戶登陸，并新建標簽頁。 這時假設管理員繼續訪問網站 B

Web安全中的CSRF代碼審計是怎樣的

頁面B上面存在攻擊者事先寫好的惡意鏈接，并誘使我們點擊

再查看用戶時，發現后臺已經不知不覺添加上了用戶

Web安全中的CSRF代碼審計是怎樣的

多了一個

這就是一次利用CSRF漏洞添加后臺的實例， 只要用戶（受害者）點擊該鏈接，就完成了一次CSRF攻擊，雖然用戶可能本身并沒有執行該操作的意圖

我們現在做個對比：

正常網站：
# Create your views here.
def transfer(request):
    if request.method=='POST':
        username=request.POST.get('username')
        to_username=request.POST.get('to_username')
        monery=request.POST.get('monery')
        print(username,to_username,monery)
return render(request,'transfer.html')
輸出：
<body>
<h2>正經網站</h2>
<form action="" method="post">
    <p>賬戶名:<input type="text" name="username"></p>
    <p>對方賬戶:<input type="text" name="to_username"></p>
    <p>轉賬金額:<input type="text" name="monery"></p>
    <input type="submit">
</form>
</body>
不正常的存在Csrf的：
#views：
def transfer(request):
    return render(request,'transfer.html')

Web安全中的CSRF代碼審計是怎樣的跳轉到了添加用戶的頁面

漏洞防御

在服務器端防御CSRF攻擊主要有四種策略

1.驗證HTTP Referer 字段：根據HTTP協議，在HTTP頭中有一個字段叫Referer，它記錄了該HTTP請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求必須來自于同一個網站。比如某銀行的轉賬是通過用戶訪問http://bank.test/test?page=10&userID=101&money=10000頁面完成，用戶必須先登錄bank.test，然后通過點擊頁面上的按鈕來觸發轉賬事件。當用戶提交請求時，該轉賬請求的Referer值就會是轉賬按鈕所在頁面的URL(本例中，通常是以bank. test域名開頭的地址)。而如果攻擊者要對銀行網站實施CSRF攻擊，他只能在自己的網站構造請求，當用戶通過攻擊者的網站發送請求到銀行時，該請求的Referer是指向攻擊者的網站。因此，要防御CSRF攻擊，銀行網站只需要對于每一個轉賬請求驗證其Referer值，如果是以bank. test開頭的域名，則說明該請求是來自銀行網站自己的請求，是合法的。如果Referer是其他網站的話，就有可能是CSRF攻擊，則拒絕該請求。

2. 在請求地址中添加token并驗證：CSRF攻擊之所以能夠成功，是因為攻擊者可以偽造用戶的請求，該請求中所有的用戶驗證信息都存在于Cookie中，因此攻擊者可以在不知道這些驗證信息的情況下直接利用用戶自己的Cookie來通過安全驗證。由此可知，抵御CSRF攻擊的關鍵在于：在請求中放入攻擊者所不能偽造的信息，并且該信息不存在于Cookie之中。鑒于此，系統開發者可以在HTTP請求中以參數的形式加入一個隨機產生的token，并在服務器端建立一個攔截器來驗證這個token，如果請求中沒有token或者token內容不正確，則認為可能是CSRF攻擊而拒絕該請求。

3. 在HTTP頭中自定義屬性并驗證：自定義屬性的方法也是使用token并進行驗證，和前一種方法不同的是，這里并不是把token以參數的形式置于HTTP請求之中，而是把它放到HTTP頭中自定義的屬性里。通過XMLHttpRequest這個類，可以一次性給所有該類請求加上csrftoken這個HTTP頭屬性，并把token值放入其中。這樣解決了前一種方法在請求中加入token的不便，同時，通過這個類請求的地址不會被記錄到瀏覽器的地址欄，也不用擔心token會通過Referer泄露到其他網站。

4. 添加驗證碼并驗證：在表單中增加一個隨機的數字或字母驗證碼，通過強制用戶和應用進行交互，來有效地遏制CSRF攻擊。

關于Web安全中的CSRF代碼審計是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

標題名稱：Web安全中的CSRF代碼審計是怎樣的
本文地址：http://vcdvsql.cn/article14/gjepde.html

成都網站建設公司_創新互聯，為您提供企業網站制作、手機網站建設、網站內鏈、靜態網站、面包屑導航、網站設計

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯

搜索引擎優化