免費(fèi)AI編程助手
Django web application security
| 先決條件: | 閱讀服務(wù)器端程序"網(wǎng)站安全"主題。 完成Django教程主題(至少包括)至少 Django教程第9部分:使用表單。 |
|---|---|
| 目的: | 理解你需要做（或不做）的主要事情來(lái)保護(hù)你的Django Web應(yīng)用程序。 |
概述
網(wǎng)站安全主題概述了網(wǎng)站安全對(duì)于服務(wù)器端設(shè)計(jì)的意義，以及一些 的你可能需要防范的更常見(jiàn)的威脅。 該文章中的一個(gè)關(guān)鍵消息是，當(dāng)Web應(yīng)用程序信任來(lái)自瀏覽器的數(shù)據(jù)時(shí)，幾乎所有攻擊都成功。
重要信息:您可以了解有關(guān)網(wǎng)站安全性的最重要的一個(gè)教訓(xùn)是不要信任來(lái)自瀏覽器的數(shù)據(jù)。 這包括網(wǎng)址參數(shù)， POST 數(shù)據(jù)，HTTP標(biāo)頭和Cookie，用戶上傳的文件等中的 GET 請(qǐng)求數(shù)據(jù)。始終檢查和清理所有傳入的數(shù)據(jù)。 總是假設(shè)最壞的。
Django用戶的好消息是，許多更常見(jiàn)的威脅都由框架處理！ Django中的安全性(Django docs)文章介紹了Django的安全功能以及如何 保護(hù)Django驅(qū)動(dòng)的網(wǎng)站。
常見(jiàn)的威脅/保護(hù)
在本文中，我們將僅演示在我們的Django LocalLibrary 教程中的一些安全功能，而不是復(fù)制Django文檔。
跨站腳本(XSS)
XSS是用于描述允許攻擊者通過(guò)網(wǎng)站將客戶端腳本注入到其他用戶的瀏覽器中的一類攻擊的術(shù)語(yǔ)。 這通常通過(guò)在數(shù)據(jù)庫(kù)中存儲(chǔ)惡意腳本來(lái)實(shí)現(xiàn)，其中可以將惡意腳本檢索并顯示給其他用戶，或者通過(guò)讓用戶單擊將導(dǎo)致攻擊者的JavaScript由用戶的瀏覽器執(zhí)行的鏈接。
Django的模板系統(tǒng)通過(guò)保護(hù)您免受大多數(shù)XSS攻擊 轉(zhuǎn)義在HTML中為"危險(xiǎn)"的特定字符。 我們可以通過(guò)嘗試使用我們?cè)?a href="/webstart/Django/Forms"> Django教程第9部分:使用表單中設(shè)置的創(chuàng)建作者表單將一些JavaScript注入我們的LocalLibrary網(wǎng)站來(lái)演示。
- Start the website using the development server (
python3 manage.py runserver). - Open the site in your local browser and login to your superuser account.
- Navigate to the author-creation page (which should be at URL:
http://127.0.0.1:8000/catalog/author/create/). - Enter names and date details for a new user, and then append the following text to the Last Name field:
<script>alert('Test alert');</script>.
注意:這是一個(gè)無(wú)害的腳本，如果執(zhí)行，會(huì)在瀏覽器中顯示一個(gè)警告框。 如果在提交記錄時(shí)顯示警報(bào)，則該站點(diǎn)容易受到XSS威脅。
- Press Submit to save the record.
- When you save the author it will be displayed as shown below. Because of the XSS protections the
alert()should not be run. Instead the script is displayed as plain text.
如果你查看頁(yè)面的HTML源代碼，你可以看到腳本標(biāo)簽的危險(xiǎn)字符已經(jīng)變成了它們無(wú)害的轉(zhuǎn)義碼等價(jià)物(例如> 現(xiàn)在& gt; / code>)
<h1>Author: Boon<script>alert('Test alert');</script>, David (Boonie) </h1>
使用Django模板保護(hù)您免受大多數(shù)XSS攻擊。 但是，可以關(guān)閉此保護(hù)，并且保護(hù)不會(huì)自動(dòng)應(yīng)用于通常不會(huì)由用戶輸入填充的所有標(biāo)記(例如，表單字段中的 help_text 通常 不是用戶提供的，所以Django不會(huì)轉(zhuǎn)義那些值)。
XSS攻擊也可能來(lái)自其他不受信任的數(shù)據(jù)源，例如Cookie，Web服務(wù)或上傳的文件(只要數(shù)據(jù)在包含在頁(yè)面中之前未被充分清理)。 如果您要顯示來(lái)自這些來(lái)源的數(shù)據(jù)，那么您可能需要添加自己的驗(yàn)證碼。
跨站點(diǎn)請(qǐng)求偽造(CSRF)保護(hù)
CSRF攻擊允許惡意用戶在沒(méi)有該用戶的知識(shí)或同意的情況下使用另一用戶的憑證來(lái)執(zhí)行動(dòng)作。 例如，假設(shè)我們有一個(gè)黑客想為我們的LocalLibrary創(chuàng)建其他作者。
注意:顯然，我們的黑客不是為了這筆錢！ 一個(gè)更有野心的黑客可以在其他網(wǎng)站上使用相同的方法來(lái)執(zhí)行更加有害的任務(wù)(例如將錢轉(zhuǎn)到自己的帳戶等)
為了做到這一點(diǎn)，他們可能創(chuàng)建一個(gè)HTML文件，如下所示，它包含一個(gè)作者創(chuàng)建表單(就像我們?cè)谏弦还?jié)中使用的)，一旦文件加載提交。 然后他們將文件發(fā)送給所有的圖書館員，并建議他們打開(kāi)文件(它包含一些無(wú)害的信息，誠(chéng)實(shí)！)。 如果文件由任何已登錄的庫(kù)管理器打開(kāi)，則將使用其憑據(jù)提交表單，并創(chuàng)建新作者。
<html>
<body onload='document.EvilForm.submit()'>
<form action="http://127.0.0.1:8000/catalog/author/create/" method="post" name='EvilForm'>
<table>
<tr><th><label for="id_first_name">First name:</label></th><td><input id="id_first_name" maxlength="100" name="first_name" type="text" value="Mad" required /></td></tr>
<tr><th><label for="id_last_name">Last name:</label></th><td><input id="id_last_name" maxlength="100" name="last_name" type="text" value="Man" required /></td></tr>
<tr><th><label for="id_date_of_birth">Date of birth:</label></th><td><input id="id_date_of_birth" name="date_of_birth" type="text" /></td></tr>
<tr><th><label for="id_date_of_death">Died:</label></th><td><input id="id_date_of_death" name="date_of_death" type="text" value="12/10/2016" /></td></tr>
</table>
<input type="submit" value="Submit" />
</form>
</body>
</html>
運(yùn)行開(kāi)發(fā)Web服務(wù)器，并使用超級(jí)用戶帳戶登錄。 將上面的文本復(fù)制到一個(gè)文件，然后在瀏覽器中打開(kāi)它。 你應(yīng)該得到一個(gè)CSRF錯(cuò)誤，因?yàn)镈jango有這種事情的保護(hù)！
啟用保護(hù)的方式是在表單定義中包含 {％csrf_token％} 模板標(biāo)記。 然后，此標(biāo)記將顯示在您的HTML中，如下所示，其中的值特定于當(dāng)前瀏覽器上的用戶。
<input type='hidden' name='csrfmiddlewaretoken' value='0QRWHnYVg776y2l66mcvZqp8alrv4lb8S8lZ4ZJUWGZFA5VHrVfL2mpH29YZ39PW' />
Django生成用戶/瀏覽器特定的鍵，并將拒絕不包含該字段或包含用戶/瀏覽器的不正確字段值的表單。
為了使用這種類型的攻擊，黑客現(xiàn)在必須發(fā)現(xiàn)并包括用于特定目標(biāo)用戶的CSRF密鑰。 他們也不能使用"scattergun"方法向所有庫(kù)管理員發(fā)送惡意文件，并希望其中一個(gè)將打開(kāi)它，因?yàn)镃SRF密鑰是特定于瀏覽器的。
默認(rèn)情況下，Django的CSRF保護(hù)功能處于打開(kāi)狀態(tài)。 您應(yīng)該始終使用表單中的 {％csrf_token％} 模板標(biāo)記，并對(duì)可能更改或向數(shù)據(jù)庫(kù)添加數(shù)據(jù)的請(qǐng)求使用 POST 。
其他保護(hù)
Django還提供其他形式的保護(hù)(大多數(shù)是困難的或不特別有用的演示):
- SQL injection protection
- SQL injection vulnerabilities enable malicious users to execute arbitrary SQL code on a database, allowing data to be accessed, modified, or deleted irrespective of the user's permissions. In almost every case you'll be accessing the database using Django’s querysets/models, so the resulting SQL will be properly escaped by the underlying database driver. If you do need to write raw queries or custom SQL then you'll need to explicitly think about preventing SQL injection.
- Clickjacking protection
- In this attack a malicious user hijacks clicks meant for a visible top level site and routes them to a hidden page beneath. This technique might be used, for example, to display a legitimate bank site but capture the login credentials in an invisible
<iframe>controlled by the attacker. Django contains clickjacking protection in the form of theX-Frame-Options middlewarewhich, in a supporting browser, can prevent a site from being rendered inside a frame. - Enforcing SSL/HTTPS
- SSL/HTTPS can be enabled on the web server in order to encrypt all traffic between the site and browser, including authentication credentials that would otherwise be sent in plain text (enabling HTTPS is highly recommended). If HTTPS is enabled then Django provides a number of other protections you can use:
-
SECURE_PROXY_SSL_HEADERcan be used to check whether content is secure, even if it is incoming from a non-HTTP proxy. -
SECURE_SSL_REDIRECTis used to redirect all HTTP requests to HTTPS. - Use HTTP Strict Transport Security (HSTS). This is an HTTP header that informs a browser that all future connections to a particular site should always use HTTPS. Combined with redirecting HTTP requests to HTTPS, this setting ensures that HTTPS is always used after a successful connection has occurred. HSTS may either be configured with
SECURE_HSTS_SECONDSandSECURE_HSTS_INCLUDE_SUBDOMAINSor on the Web server. - Use ‘secure’ cookies by setting
SESSION_COOKIE_SECUREandCSRF_COOKIE_SECUREtoTrue. This will ensure that cookies are only ever sent over HTTPS.
- Host header validation
- Use
ALLOWED_HOSTSto only accept requests from trusted hosts.
還有許多其他保護(hù)，并注意到使用上述機(jī)制。 雖然我們希望這給了你Django提供的概述，你應(yīng)該仍然閱讀Django安全文檔。
概要
Django有針對(duì)一些常見(jiàn)威脅的有效保護(hù)，包括XSS和CSRF攻擊。 在本文中，我們已經(jīng)在我們的 LocalLibrary 網(wǎng)站中演示了Django如何處理這些特定威脅。 我們還提供了一些其他保護(hù)的簡(jiǎn)要概述。
這是一個(gè)非常簡(jiǎn)短的web安全。 我們強(qiáng)烈建議您閱讀 Django中的安全性，以獲得更深入的了解。
本單元中關(guān)于Django的下一步和最后一步是完成評(píng)估任務(wù)。
也可以看看
- Security in Django (Django docs)
- Server side website security (MDN)
- Web security (MDN)
- Securing your site (MDN)
更多建議：