Django 的安全性

跨站點(diǎn)腳本（XSS）保護(hù)

XSS攻擊使用戶可以將客戶端腳本注入其他用戶的瀏覽器中。通常，這是通過將惡意腳本存儲(chǔ)在數(shù)據(jù)庫中進(jìn)行檢索并將其顯示給其他用戶，或者通過使用戶單擊鏈接而導(dǎo)致攻擊者的JavaScript由用戶的瀏覽器執(zhí)行來實(shí)現(xiàn)的。但是，只要未在包含在頁面中之前對(duì)數(shù)據(jù)進(jìn)行足夠的清理，XSS攻擊就可能源自任何不受信任的數(shù)據(jù)源，例如cookie或Web服務(wù)。

使用Django模板可以保護(hù)您免受大多數(shù)XSS攻擊。但是，重要的是要了解其提供的保護(hù)及其限制。

Django模板會(huì)轉(zhuǎn)義特定字符 ，這對(duì)于HTML來說尤其危險(xiǎn)。盡管這可以保護(hù)用戶免受大多數(shù)惡意輸入的侵害，但這并不是絕對(duì)安全的。例如，它將不會(huì)保護(hù)以下內(nèi)容：

<style class={{ var }}>...</style>

如果var將設(shè)置為，則可能導(dǎo)致未經(jīng)授權(quán)的JavaScript執(zhí)行，具體取決于瀏覽器如何呈現(xiàn)不完美的HTML。（引用屬性值將解決這種情況。）'class1 onmouseover=javascript:func()'

is_safe與自定義模板標(biāo)簽，safe模板標(biāo)簽一起使用mark_safe以及關(guān)閉自動(dòng)轉(zhuǎn)義功能時(shí)，請(qǐng)務(wù)必特別小心。

此外，如果您使用模板系統(tǒng)輸出HTML以外的內(nèi)容，則可能會(huì)有完全分開的字符和單詞需要轉(zhuǎn)義。

在數(shù)據(jù)庫中存儲(chǔ)HTML時(shí)，也應(yīng)特別小心，尤其是在檢索和顯示HTML時(shí)。

跨站點(diǎn)請(qǐng)求偽造（CSRF）保護(hù)

CSRF攻擊允許惡意用戶使用另一用戶的憑據(jù)執(zhí)行操作，而無需該用戶的知識(shí)或同意。

Django具有針對(duì)大多數(shù)CSRF攻擊的內(nèi)置保護(hù)，只要您在適當(dāng)?shù)牡胤絾⒂煤褪褂盟纯?。但是，與任何緩解技術(shù)一樣，存在局限性。例如，可以全局禁用或針對(duì)特定視圖禁用CSRF模塊。僅當(dāng)您知道自己在做什么時(shí)，才應(yīng)該這樣做。如果您的站點(diǎn)具有您無法控制的子域，則還有其他限制。

CSRF保護(hù)通過檢查每個(gè)POST請(qǐng)求中的秘密來起作用。這樣可以確保惡意用戶無法將表單POST“重播”到您的網(wǎng)站，而讓另一個(gè)登錄用戶無意間提交該表單。惡意用戶必須知道特定于用戶的秘密（使用cookie）。

與HTTPS一起部署時(shí)， CsrfViewMiddleware將檢查HTTP引用標(biāo)頭是否設(shè)置為同一來源（包括子域和端口）上的URL。因?yàn)镠TTPS提供了額外的安全性，所以必須通過轉(zhuǎn)發(fā)不安全的連接請(qǐng)求并對(duì)支持的瀏覽器使用HSTS來確保連接使用HTTPS可用的連接。

csrf_exempt除非絕對(duì)必要，否則請(qǐng)小心用裝飾器標(biāo)記視圖。

SQL注入防護(hù)

SQL注入是一種攻擊，惡意用戶能夠在數(shù)據(jù)庫上執(zhí)行任意SQL代碼。這可能導(dǎo)致記錄被刪除或數(shù)據(jù)泄漏。

由于Django的查詢集是使用查詢參數(shù)化構(gòu)造的，因此可以防止SQL注入。查詢的SQL代碼是與查詢的參數(shù)分開定義的。由于參數(shù)可能是用戶提供的，因此是不安全的，因此底層數(shù)據(jù)庫驅(qū)動(dòng)程序會(huì)對(duì)其進(jìn)行轉(zhuǎn)義。

Django還使開發(fā)人員可以編寫原始查詢或執(zhí)行自定義sql。這些功能應(yīng)謹(jǐn)慎使用，并且您應(yīng)始終小心謹(jǐn)慎地轉(zhuǎn)義用戶可以控制的任何參數(shù)。此外，使用extra() 和時(shí)應(yīng)格外小心RawSQL。

點(diǎn)擊劫持保護(hù)

點(diǎn)擊劫持是一種攻擊，其中惡意站點(diǎn)將另一個(gè)站點(diǎn)包裝在框架中。這種攻擊可能導(dǎo)致毫無戒心的用戶被誘騙在目標(biāo)站點(diǎn)上執(zhí)行意外的操作。

Django包含clickjacking保護(hù)，其形式為 在支持的瀏覽器中可以防止網(wǎng)站在框架內(nèi)呈現(xiàn)?？梢曰诿總€(gè)視圖禁用保護(hù)或配置發(fā)送的確切報(bào)頭值。X-Frame-Options middleware

強(qiáng)烈建議將中間件用于任何不需要第三方站點(diǎn)將其頁面包裝在框架中的站點(diǎn)，或者只需要允許站點(diǎn)的一小部分使用該中間件。

SSL / HTTPS

在HTTPS后面部署站點(diǎn)對(duì)于安全性而言總是更好的選擇。否則，惡意網(wǎng)絡(luò)用戶可能會(huì)嗅探身份驗(yàn)證憑據(jù)或客戶端與服務(wù)器之間傳輸?shù)娜魏纹渌畔?，并且在某些情況下（活動(dòng)的網(wǎng)絡(luò)攻擊者）可能會(huì)更改沿任一方向發(fā)送的數(shù)據(jù)。

如果您想要HTTPS提供的保護(hù)并已在服務(wù)器上啟用了該保護(hù)，則可能需要執(zhí)行一些其他步驟：

• 如有必要，請(qǐng)?jiān)O(shè)置SECURE_PROXY_SSL_HEADER，以確保您已充分了解其中的警告。否則可能會(huì)導(dǎo)致CSRF漏洞，而如果不正確做則也很危險(xiǎn)！
• 設(shè)置SECURE_SSL_REDIRECT為True，以便將通過HTTP的請(qǐng)求重定向到HTTPS。請(qǐng)注意下的警告SECURE_PROXY_SSL_HEADER。對(duì)于反向代理，配置主Web服務(wù)器以重定向到HTTPS可能更容易或更安全。
• 使用“安全” cookie。如果瀏覽器最初是通過HTTP連接（這是大多數(shù)瀏覽器的默認(rèn)設(shè)置），則可能會(huì)泄漏現(xiàn)有的Cookie。因此，您應(yīng)將SESSION_COOKIE_SECURE和 CSRF_COOKIE_SECURE設(shè)置設(shè)置為True。這指示瀏覽器僅通過HTTPS連接發(fā)送這些cookie。請(qǐng)注意，這將意味著會(huì)話將無法通過HTTP進(jìn)行工作，并且CSRF保護(hù)將阻止通過HTTP接受任何POST數(shù)據(jù)（如果您將所有HTTP流量都重定向到HTTPS，這將很好）。
• 使用HTTP嚴(yán)格傳輸安全性（HSTS）HSTS是一個(gè)HTTP標(biāo)頭，它通知瀏覽器將來與特定站點(diǎn)的所有連接都應(yīng)始終使用HTTPS。結(jié)合通過HTTP將請(qǐng)求重定向到HTTPS，這將確保只要發(fā)生一次成功的連接，連接就始終可以享受SSL的額外安全性。HSTS既可以與配置SECURE_HSTS_SECONDS， SECURE_HSTS_INCLUDE_SUBDOMAINS以及SECURE_HSTS_PRELOAD，或在Web服務(wù)器上。

主機(jī)頭驗(yàn)證

Host在某些情況下，Django使用客戶端提供的標(biāo)頭構(gòu)造URL。盡管清除了這些值以防止跨站點(diǎn)腳本攻擊，但偽造的Host值可用于跨站點(diǎn)請(qǐng)求偽造，緩存中毒攻擊和電子郵件中的中毒鏈接。

因?yàn)榧词箍此瓢踩腤eb服務(wù)器配置也容易受到偽造的 Host標(biāo)頭的影響，所以Django會(huì)根據(jù)方法Host中的ALLOWED_HOSTS設(shè)置來 驗(yàn)證標(biāo)頭 django.http.HttpRequest.get_host()。

此驗(yàn)證僅通過get_host()；如果您的代碼Host直接從request.META您訪問標(biāo)頭，則會(huì)繞過此安全保護(hù)。

有關(guān)更多詳細(xì)信息，請(qǐng)參見完整ALLOWED_HOSTS文檔。

警告：本文檔的先前版本建議配置Web服務(wù)器，以確保它驗(yàn)證傳入的HTTP Host標(biāo)頭。盡管仍然建議這樣做，但是在許多常見的Web服務(wù)器中，似乎可以驗(yàn)證Host標(biāo)頭的配置實(shí)際上可能沒有這樣做。例如，即使將Apache配置為從具有該ServerName設(shè)置的非默認(rèn)虛擬主機(jī)為Django站點(diǎn)提供服務(wù)，HTTP請(qǐng)求仍然有可能匹配該虛擬主機(jī)并提供??偽造的Host標(biāo)頭。因此，Django現(xiàn)在要求您進(jìn)行ALLOWED_HOSTS顯式設(shè)置，而不是依賴于Web服務(wù)器配置。

此外，如果您的配置需要Django，則Django要求您顯式啟用對(duì)X-Forwarded-Host標(biāo)頭的支持 （通過USE_X_FORWARDED_HOST設(shè)置）。

推薦人政策

瀏覽器使用Referer標(biāo)頭作為向用戶發(fā)送有關(guān)用戶到達(dá)那里的信息的方式。通過設(shè)置引薦來源網(wǎng)址策略，您可以幫助保護(hù)用戶的隱私，并限制在哪種情況下設(shè)置 Referer標(biāo)頭。有關(guān)詳細(xì)信息，請(qǐng)參見安全中間件參考的引薦來源網(wǎng)址策略部分。

會(huì)話安全

與CSRF的限制類似，它要求部署網(wǎng)站以使不受信任的用戶無法訪問任何子域，這 django.contrib.sessions也有限制。有關(guān)詳細(xì)信息，請(qǐng)參見有關(guān)安全性的會(huì)話主題指南部分。

用戶上傳的內(nèi)容

注意：考慮從云服務(wù)或CDN提供靜態(tài)文件，以避免其中的某些問題。

• 如果您的站點(diǎn)接受文件上傳，則強(qiáng)烈建議您將Web服務(wù)器配置中的這些上傳限制為合理的大小，以防止拒絕服務(wù)（DOS）攻擊。在Apache中，可以使用LimitRequestBody指令輕松設(shè)置此值。
• 如果您要提供自己的靜態(tài)文件，請(qǐng)確保mod_php禁用諸如Apache的處理程序，該處理程序 將靜態(tài)文件作為代碼執(zhí)行。您不希望用戶能夠通過上載和請(qǐng)求特制文件來執(zhí)行任意代碼。
• 當(dāng)以不遵循安全最佳實(shí)踐的方式提供媒體時(shí)，Django的媒體上傳處理會(huì)帶來一些漏洞。具體來說，如果HTML文件包含有效的PNG標(biāo)頭和惡意HTML，則該HTML文件可以作為圖像上傳。該文件將通過Django用于ImageField圖像處理的庫的驗(yàn)證（枕頭）。隨后將該文件顯示給用戶時(shí)，根據(jù)您的Web服務(wù)器的類型和配置，它可能會(huì)顯示為HTML。在框架級(jí)別沒有可以安全驗(yàn)證所有用戶上傳文件內(nèi)容的防彈技術(shù)解決方案，但是，您可以采取一些其他步驟來減輕這些攻擊：通過始終為來自不同的頂級(jí)域或第二級(jí)域的用戶上傳的內(nèi)容提供服務(wù)，可以防止一類攻擊。這樣可以防止任何由同源策略保護(hù)（例如跨站點(diǎn)腳本）阻止的漏洞利用。例如，如果您的網(wǎng)站在上運(yùn)行example.com，您可能希望通過來提供上載的內(nèi)容（MEDIA_URL設(shè)置）usercontent-example.com。這是不是足以從像一個(gè)子域提供內(nèi)容usercontent.example.com。除此之外，應(yīng)用程序可能會(huì)選擇為用戶上傳的文件定義允許的文件擴(kuò)展名白名單，并將Web服務(wù)器配置為僅提供此類文件。

其他安全主題

盡管Django提供了開箱即用的良好安全保護(hù)，但是正確部署應(yīng)用程序并利用Web服務(wù)器，操作系統(tǒng)和其他組件的安全保護(hù)仍然很重要。

• 確保您的Python代碼在Web服務(wù)器根目錄之外。這將確保您的Python代碼不會(huì)意外地用作純文本（或意外地執(zhí)行）。
• 注意任何用戶上傳的文件。
• Django不會(huì)限制對(duì)用戶進(jìn)行身份驗(yàn)證的請(qǐng)求。為了防止對(duì)身份驗(yàn)證系統(tǒng)的暴力攻擊，您可以考慮部署Django插件或Web服務(wù)器模塊來限制這些請(qǐng)求。
• 保守SECRET_KEY秘密
• 最好使用防火墻限制緩存系統(tǒng)和數(shù)據(jù)庫的可訪問性。
• 查看開放式Web應(yīng)用程序安全項(xiàng)目（OWASP）的前10個(gè)列表，該列表確定了Web應(yīng)用程序中的一些常見漏洞。盡管Django擁有解決某些問題的工具，但在項(xiàng)目設(shè)計(jì)中必須考慮其他問題。
• Mozilla討論了有關(guān)Web安全的各種主題。他們的頁面還包含適用于任何系統(tǒng)的安全性原則。

詳情參考： https://docs.djangoproject.com/en/3.0/