Django 的安全性

跨站點腳本（XSS）保護

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

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

Django模板會轉(zhuǎn)義特定字符 ，這對于HTML來說尤其危險。盡管這可以保護用戶免受大多數(shù)惡意輸入的侵害，但這并不是絕對安全的。例如，它將不會保護以下內(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與自定義模板標簽，safe模板標簽一起使用mark_safe以及關(guān)閉自動轉(zhuǎn)義功能時，請務(wù)必特別小心。

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

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

跨站點請求偽造（CSRF）保護

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

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

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

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

csrf_exempt除非絕對必要，否則請小心用裝飾器標記視圖。

SQL注入防護

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

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

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

點擊劫持保護

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

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

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

SSL / HTTPS

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

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

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

主機頭驗證

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

因為即使看似安全的Web服務(wù)器配置也容易受到偽造的 Host標頭的影響，所以Django會根據(jù)方法Host中的ALLOWED_HOSTS設(shè)置來 驗證標頭 django.http.HttpRequest.get_host()。

此驗證僅通過get_host()；如果您的代碼Host直接從request.META您訪問標頭，則會繞過此安全保護。

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

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

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

推薦人政策

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

會話安全

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

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

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

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

其他安全主題

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

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

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