• 歡迎訪問奇跡の海網站,本站不上傳任何資源,所有資源均來自于網絡,歡迎加入奇跡の海~!奇跡の海-WordPress QQ群
  • 本站下載資源為網絡上收集整理而來,并且以計算機技術研究交流為目的,版權歸原作者所有,僅供大家參考,學習,不存在任何商業目的與商業用途.
  • 本站系統鏡像均來自于官方原版,ed2k可視為P2P下載鏈接。所有操作系統默認均為試用版,如有正版密鑰可以有效激活,本站不提供任何激活和相關服務。

Web安全教程之CSRF(跨站點請求偽造)

WEB服務 奇跡の海 2年前 (2017-10-30) 831次瀏覽 已收錄 0個評論 掃描二維碼

前端面試過程中遇到的另一個最多的問題就是web安全了,之前博客有分享過XSS攻擊的內容,這次聊聊CSRF攻擊。CSRF是一種常見的攻擊,但是也是web安全中最容易被忽略的一種攻擊方式。
Web安全教程之CSRF(跨站點請求偽造)

什么是CSRF(跨站點請求偽造)

根據字面意思,大概能猜到,CSRF攻擊就是攻擊者偽造了用戶的請求,在用戶不知道的情況下,以用戶的名義向服務器發送惡意請求。常見的場景是,用戶首先登陸一個正常(下面稱為被攻擊網站)的網站,攻擊者誘使用戶在不關閉被攻擊網站的同時打開攻擊者的頁面,這時攻擊者就可以以用戶的名義給被攻擊網站發送惡意請求了。可以看出CSRF是有條件的,首先用戶要登陸被攻擊網站,并生成Cookie,然后在不登出被攻擊網站的同時,訪問攻擊網站。這兩個條件缺一不可。

CSRF進階

瀏覽器Cookie策略

CSRF之所以能成功,主要還是因為用戶的瀏覽器成功發送了Cookie的緣故。瀏覽器所持有的Cookie分為兩種:一種是“Session Cookie”,又叫“臨時Cookie”;另一種是“Third-party Cookie”,也稱為“本地Cookie”。
Third-party Cookie,服務器在Set-Cookie時指定了Expire時間,只有到了Expire時間后Cookie才會失效,而Session Cookie則沒有指定Expire時間,瀏覽器關閉后就失效了。如果瀏覽器從一個域的頁面中,要加載另一個域的資源,由于安全原因,某些瀏覽器會阻止Third-party Cookie的發送。由于新打開的頁面和原來的頁面在同一個瀏覽器進程中,所以Session Cookie將會被發送。

IE瀏覽器處于安全考慮是禁止瀏覽器在<img>、<iframe>、<script>、<link>等標簽中發送第三方Cookie的。當前的主流瀏覽器中,默認會攔截Third-party Cookie的有:IE6~8、Safari,不會攔截的有:Firefox、Opera、Chrome等。

只有GET請求么?

在CSRF攻擊流行之初,有一種錯誤的觀點認為CSRF攻擊只能由GET發起,這種錯誤觀點的形成原因是大多數CSRF攻擊發起時,使用的HTML標簽都是<img>、<iframe>、<script>等帶src屬性的標簽,這列標簽只能夠發起一次GET請求,而不能發起POST請求。然而,對于攻擊者來說,有若干種方法可以構造出一個POST請求。最簡單的方法就是在一個頁面中構造好一個form表單,然后使用javascript自動提交這個表單。

<form action="http://www.a.com/register" id="register" method="post" accept-charset="utf-8">
<input type="text" name="username" value=""/>
<input type="password" name="password" value=""/>
<input type="submit" name="submit" value="submit"/>
</form>
<script>
var f = document.getElementById("register");
f.inputs[0].value = "test";
f.inputs[1].value = "passwd";
f.submit();
</script>

CSRF防御

驗證碼

驗證碼是對抗CSRF攻擊最簡單有效地防御方法。CSRF攻擊往往是在用戶不知情的情況下構造了網絡請求。而驗證碼則強制用戶必須與應用進行交互,才能完成最終請求。
但是驗證碼并不是萬能的,我們不可能給頁面的所有操作都加上驗證碼。

Referer Check

Referer Check在互聯網中最常見的應用就是“防止圖片盜鏈”。同理,Referer Check也可以被用于檢查請求是否來自合法的源。

Anti CSRF Token

CSRF攻擊存在的本質原因還是網頁中重要操作的所有參數都是可以被攻擊者猜測到的。攻擊者只有預測出url所有參數與參數值,才能成功地構造一個偽造的請求。所以我們可以通過把參數加密,或者使用一些隨機數,從而讓攻擊者無法猜測到參數值。
我們可以給請求新增加一個token,這個token值是隨機的。

http://host/path/delete?username=abc&item=123&token=[random(seed)]

由于token的存在,攻擊者就無法再構造出一個完整的url來實施CSRF攻擊了。

原文:Hieeyh’s blog


版權聲明:本站所有文章和資源使用CC BY-NC-SA 4.0協議授權發布 , 轉載應當以相同方式注明文章來自“SeaOMC.COM->Web安全教程之CSRF(跨站點請求偽造)!在下邊可以分享本文哦!
喜歡 (1)
[]
分享 (0)
奇跡の海
關于作者:
一個WordPress菜鳥!
發表我的評論
取消評論

表情 貼圖 加粗 刪除線 居中 斜體 簽到

Hi,您需要填寫昵稱和郵箱!

  • 昵稱 (必填)
  • 郵箱 (必填)
  • 網址
中国福利彩票36选7开奖结果