Django中如何防范CSRF跨站點(diǎn)請(qǐng)求偽造攻擊的實(shí)現(xiàn)-創(chuàng)新互聯(lián)

CSRF概念

成都創(chuàng)新互聯(lián)公司長(zhǎng)期為1000多家客戶(hù)提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開(kāi)放共贏平臺(tái)，與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為雙遼企業(yè)提供專(zhuān)業(yè)的網(wǎng)站建設(shè)、成都網(wǎng)站制作，雙遼網(wǎng)站改版等技術(shù)服務(wù)。擁有十年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開(kāi)發(fā)。

CSRF跨站點(diǎn)請(qǐng)求偽造(Cross—Site Request Forgery)。

攻擊者盜用了你的身份，以你的名義發(fā)送惡意請(qǐng)求，對(duì)服務(wù)器來(lái)說(shuō)這個(gè)請(qǐng)求是完全合法的，但是卻完成了攻擊者所期望的一個(gè)操作，比如以你的名義發(fā)送郵件、發(fā)消息，盜取你的賬號(hào)，添加系統(tǒng)管理員，甚至于購(gòu)買(mǎi)商品、虛擬貨幣轉(zhuǎn)賬等。

CSRF攻擊原理以及過(guò)程


用戶(hù)C打開(kāi)瀏覽器，訪問(wèn)受信任網(wǎng)站A，輸入用戶(hù)名和密碼請(qǐng)求登錄網(wǎng)站A；

在用戶(hù)信息通過(guò)驗(yàn)證后，網(wǎng)站A產(chǎn)生Cookie信息并返回給瀏覽器，此時(shí)用戶(hù)登錄網(wǎng)站A成功，可以正常發(fā)送請(qǐng)求到網(wǎng)站A；

用戶(hù)未退出網(wǎng)站A之前，在同一瀏覽器中，打開(kāi)一個(gè)TAB頁(yè)訪問(wèn)網(wǎng)站B；

網(wǎng)站B接收到用戶(hù)請(qǐng)求后，返回一些攻擊性代碼，并發(fā)出一個(gè)請(qǐng)求要求訪問(wèn)第三方站點(diǎn)A；

瀏覽器在接收到這些攻擊性代碼后，根據(jù)網(wǎng)站B的請(qǐng)求，在用戶(hù)不知情的情況下攜帶Cookie信息，向網(wǎng)站A發(fā)出請(qǐng)求。網(wǎng)站A并不知道該請(qǐng)求其實(shí)是由B發(fā)起的，所以會(huì)根據(jù)用戶(hù)C的Cookie信息以C的權(quán)限處理該請(qǐng)求，導(dǎo)致來(lái)自網(wǎng)站B的惡意代碼被執(zhí)行。

CSRF攻擊實(shí)例


受害者 Bob 在銀行有一筆存款，通過(guò)對(duì)銀行的網(wǎng)站發(fā)送請(qǐng)求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2可以使 Bob 把 1000000 的存款轉(zhuǎn)到 bob2 的賬號(hào)下。通常情況下，該請(qǐng)求發(fā)送到網(wǎng)站后，服務(wù)器會(huì)先驗(yàn)證該請(qǐng)求是否來(lái)自一個(gè)合法的 session，并且該 session 的用戶(hù) Bob 已經(jīng)成功登陸。

黑客 Mallory 自己在該銀行也有賬戶(hù)，他知道上文中的 URL 可以把錢(qián)進(jìn)行轉(zhuǎn)帳操作。Mallory 可以自己發(fā)送一個(gè)請(qǐng)求給銀行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是這個(gè)請(qǐng)求來(lái)自 Mallory 而非 Bob，他不能通過(guò)安全認(rèn)證，因此該請(qǐng)求不會(huì)起作用。

這時(shí)，Mallory 想到使用 CSRF 的攻擊方式，他先自己做一個(gè)網(wǎng)站，在網(wǎng)站中放入如下代碼：src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并且通過(guò)廣告等誘使 Bob 來(lái)訪問(wèn)他的網(wǎng)站。當(dāng) Bob 訪問(wèn)該網(wǎng)站時(shí)，上述 url 就會(huì)從 Bob 的瀏覽器發(fā)向銀行，而這個(gè)請(qǐng)求會(huì)附帶 Bob 瀏覽器中的 cookie 一起發(fā)向銀行服務(wù)器。大多數(shù)情況下，該請(qǐng)求會(huì)失敗，因?yàn)樗?Bob 的認(rèn)證信息。但是，如果 Bob 當(dāng)時(shí)恰巧剛訪問(wèn)他的銀行后不久，他的瀏覽器與銀行網(wǎng)站之間的 session 尚未過(guò)期，瀏覽器的 cookie 之中含有 Bob 的認(rèn)證信息。這時(shí)，悲劇發(fā)生了，這個(gè) url 請(qǐng)求就會(huì)得到響應(yīng)，錢(qián)將從 Bob 的賬號(hào)轉(zhuǎn)移到 Mallory 的賬號(hào)，而 Bob 當(dāng)時(shí)毫不知情。等以后 Bob 發(fā)現(xiàn)賬戶(hù)錢(qián)少了，即使他去銀行查詢(xún)?nèi)罩荆仓荒馨l(fā)現(xiàn)確實(shí)有一個(gè)來(lái)自于他本人的合法請(qǐng)求轉(zhuǎn)移了資金，沒(méi)有任何被攻擊的痕跡。而 Mallory 則可以拿到錢(qián)后逍遙法外。

Django中如何防范CSRF

Django使用專(zhuān)門(mén)的中間件（CsrfMiddleware）來(lái)進(jìn)行CSRF防護(hù)。具體的原理如下：

1.它修改當(dāng)前處理的請(qǐng)求，向所有的 POST 表單增添一個(gè)隱藏的表單字段，使用名稱(chēng)是 csrfmiddlewaretoken ，值為當(dāng)前會(huì)話(huà) ID 加上一個(gè)密鑰的散列值。 如果未設(shè)置會(huì)話(huà) ID ，該中間件將不會(huì)修改響應(yīng)結(jié)果，因此對(duì)于未使用會(huì)話(huà)的請(qǐng)求來(lái)說(shuō)性能損失是可以忽略的。

2.對(duì)于所有含會(huì)話(huà) cookie 集合的傳入 POST 請(qǐng)求，它將檢查是否存在 csrfmiddlewaretoken 及其是否正確。 如果不是的話(huà)，用戶(hù)將會(huì)收到一個(gè) 403 HTTP 錯(cuò)誤。 403 錯(cuò)誤頁(yè)面的內(nèi)容是檢測(cè)到了跨域請(qǐng)求偽裝。 終止請(qǐng)求。

該步驟確保只有源自你的站點(diǎn)的表單才能將數(shù)據(jù) POST 回來(lái)。

另外要說(shuō)明的是，未使用會(huì)話(huà) cookie 的 POST 請(qǐng)求無(wú)法受到保護(hù)，但它們也不 需要 受到保護(hù)，因?yàn)閻阂饩W(wǎng)站可用任意方法來(lái)制造這種請(qǐng)求。為了避免轉(zhuǎn)換非 HTML 請(qǐng)求，中間件在編輯響應(yīng)結(jié)果之前對(duì)它的 Content-Type 頭標(biāo)進(jìn)行檢查。 只有標(biāo)記為 text/html 或 application/xml+xhtml 的頁(yè)面才會(huì)被修改。

Django防范CSRF的具體操作


1. 將'django.middleware.csrf.CsrfViewMiddleware'添加到Django的settings.py文件中的MIDDLEWARE_CLASSES列表中（默認(rèn)已經(jīng)添加）。 該中間件必須在 SessionMiddleware 之后執(zhí)行，因此在列表中 CsrfMiddleware 必須出現(xiàn)在SessionMiddleware 之前 （因?yàn)轫憫?yīng)中間件是自后向前執(zhí)行的）。 同時(shí)，它也必須在響應(yīng)被壓縮或解壓之前對(duì)響應(yīng)結(jié)果進(jìn)行處理，因此CsrfMiddleware必須在GZipMiddleware之后執(zhí)行。

MIDDLEWARE_CLASSES = (
  'django.middleware.common.CommonMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.contrib.messages.middleware.MessageMiddleware',
  # Uncomment the next line for simple clickjacking protection:
  # 'django.middleware.clickjacking.XFrameOptionsMiddleware',
)

分享名稱(chēng)：Django中如何防范CSRF跨站點(diǎn)請(qǐng)求偽造攻擊的實(shí)現(xiàn)-創(chuàng)新互聯(lián)
網(wǎng)站網(wǎng)址：http://bm7419.com/article32/cecosc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開(kāi)發(fā)、域名注冊(cè)、定制開(kāi)發(fā)、網(wǎng)站建設(shè)、ChatGPT、小程序開(kāi)發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)

成都做網(wǎng)站