警告

安全研究員最近發(fā)現(xiàn)，當壓縮技術(shù)（包括GZipMiddleware）用于一個網(wǎng)站的時候，網(wǎng)站會受到一些可能的攻擊。此外，這些方法可以用于破壞Django的CSRF保護。在你的站點使用GZipMiddleware之前，你應該先仔細考慮一下你的站點是否容易受到這些攻擊。如果你不確定是否會受到這些影響，應該避免使用 GZipMiddleware。詳見the BREACH paper (PDF)和breachattack.com。

為支持GZip壓縮的瀏覽器（一些現(xiàn)代的瀏覽器）壓縮內(nèi)容。

建議把這個中間件放到中間件配置列表的第一個，這樣壓縮響應內(nèi)容的處理會到最后才發(fā)生。

如果滿足下面條件的話，內(nèi)容不會被壓縮：

消息體的長度小于200個字節(jié)。
響應已經(jīng)設置了Content-Encoding協(xié)議頭。
請求（瀏覽器）沒有發(fā)送包含gzip的Accept-Encoding協(xié)議頭。

你可以通過這個gzip_page()裝飾器使用獨立的GZip壓縮。

帶條件判斷的GET中間件

class ConditionalGetMiddleware[source]

處理帶有條件判斷狀態(tài)GET操作。如果一個請求包含 ETag 或者Last-Modified協(xié)議頭，并且請求包含If-None-Match或If-Modified-Since，這時響應會被替換為HttpResponseNotModified。

另外，它會設置Date和Content-Length響應頭。

本地中間件

class LocaleMiddleware[source]

基于請求中的數(shù)據(jù)開啟語言選擇。它可以為每個用戶進行定制。詳見國際化文檔。

LocaleMiddleware.response_redirect_class

默認為HttpResponseRedirect。繼承自LocaleMiddleware并覆寫了屬性來自定義中間件發(fā)出的重定向。

消息中間件

class MessageMiddleware[source]

開啟基于cookie或會話的消息支持。詳見消息文檔。

安全中間件

警告

如果你的部署環(huán)境允許的話，讓你的前端web服務器展示SecurityMiddleware提供的功能是個好主意。這樣一來，如果有任何請求沒有被Django處理（比如靜態(tài)媒體或用戶上傳的文件），他們會擁有和向Django應用的請求相同的保護。

class SecurityMiddleware[source]

Django 1.8中新增

django.middleware.security.SecurityMiddleware為請求/響應循環(huán)提供了幾種安全改進。每一種可以通過一個選項獨立開啟或關(guān)閉。

SECURE_BROWSER_XSS_FILTER
SECURE_CONTENT_TYPE_NOSNIFF
SECURE_HSTS_INCLUDE_SUBDOMAINS
SECURE_HSTS_SECONDS
SECURE_REDIRECT_EXEMPT
SECURE_SSL_HOST
SECURE_SSL_REDIRECT

HTTP Strict Transport Security (HSTS)

對于那些應該只能通過HTTPS訪問的站點，你可以通過設置HSTS協(xié)議頭，通知現(xiàn)代的瀏覽器，拒絕用不安全的連接來連接你的域名。這會降低你受到SSL-stripping的中間人（MITM）攻擊的風險。

如果你將SECURE_HSTS_SECONDS設置為一個非零值，SecurityMiddleware會在所有的HTTPS響應中設置這個協(xié)議頭。

開啟HSTS的時候，首先使用一個小的值來測試它是個好主意，例如，讓SECURE_HSTS_SECONDS = 3600為一個小時。每當瀏覽器在你的站點看到HSTS協(xié)議頭，都會在提供的時間段內(nèi)絕對使用不安全（HTTP）的方式連接到你的域名。一旦你確認你站點上的所有東西都以安全的方式提供（例如，HSTS并不會干擾任何事情），建議你增加這個值，這樣不常訪問你站點的游客也會被保護（比如，一般設置為31536000秒，一年）。

另外，如果你將 SECURE_HSTS_INCLUDE_SUBDOMAINS設置為True,，SecurityMiddleware會將includeSubDomains標簽添加到Strict-Transport-Security協(xié)議頭中。強烈推薦這樣做（假設所有子域完全使用HTTPS），否則你的站點仍舊有可能由于子域的不安全連接而受到攻擊。

警告

HSTS策略在你的整個域中都被應用，不僅僅是你所設置協(xié)議頭的響應中的url。所以，如果你的整個域都設置為HTTPS only，你應該只使用HSTS策略。

適當遵循HSTS協(xié)議頭的瀏覽器，會通過顯示警告的方式，拒絕讓用戶連接到證書過期的、自行簽署的、或者其他SSL證書無效的站點。如果你使用了HSTS，確保你的證書處于一直有效的狀態(tài)！

注意

如果你的站點部署在負載均衡器或者反向代理之后，并且Strict-Transport-Security協(xié)議頭沒有添加到你的響應中，原因是Django有可能意識不到這是一個安全連接。你可能需要設置SECURE_PROXY_SSL_HEADER。

X-Content-Type-Options: nosniff

一些瀏覽器會嘗試猜測他們所得內(nèi)容的類型，而不是讀取Content-Type協(xié)議頭。雖然這樣有助于配置不當?shù)姆掌髡ｏ@示內(nèi)容，但也會導致安全問題。

如果你的站點允許用戶上傳文件，一些惡意的用戶可能會上傳一個精心構(gòu)造的文件，當你覺得它無害的時候，文件會被瀏覽器解釋成HTML或者Javascript。

欲知更多有關(guān)這個協(xié)議頭和瀏覽器如何處理它的內(nèi)容，你可以在IE安全博客中讀到它。

要防止瀏覽器猜測內(nèi)容類型，并且強制它一直使用 Content-Type協(xié)議頭中提供的類型，你可以傳遞X-Content-Type-Options: nosniff協(xié)議頭。SecurityMiddleware將會對所有響應這樣做，如果SECURE_CONTENT_TYPE_NOSNIFF 設置為True。

注意在大多數(shù)Django不涉及處理上傳文件的部署環(huán)境中，這個設置不會有任何幫助。例如，如果你的MEDIA_URL被前端web服務器直接處理（例如nginx和Apache），你可能想要在那里設置這個協(xié)議頭。而在另一方面，如果你使用Django執(zhí)行為了下載文件而請求授權(quán)之類的事情，并且你不能使用你的web服務器設置協(xié)議頭，這個設置會很有用。

X-XSS-Protection: 1; mode=block

一些瀏覽器能夠屏蔽掉出現(xiàn)XSS攻擊的內(nèi)容。通過尋找頁面中GET或者POST參數(shù)中的JavaScript內(nèi)容來實現(xiàn)。如果JavaScript在服務器的響應中被重放，頁面就會停止渲染，并展示一個錯誤頁來取代。

X-XSS-Protection協(xié)議頭用來控制XSS過濾器的操作。

要在瀏覽器中啟用XSS過濾器，并且強制它一直屏蔽可疑的XSS攻擊，你可以在協(xié)議頭中傳遞X-XSS-Protection: 1; mode=block。如果SECURE_BROWSER_XSS_FILTER設置為True，SecurityMiddleware會在所有響應中這樣做。

警告

瀏覽器的XSS過濾器是一個十分有效的手段，但是不要過度依賴它。它并不能檢測到所有的XSS攻擊，也不是所有瀏覽器都支持這一協(xié)議頭。確保你校驗和過濾了所有的輸入來防止XSS攻擊。

SSL重定向

如果你同時提供HTTP和HTTPS連接，大多數(shù)用戶會默認使用不安全的（HTTP）鏈接。為了更高的安全性，你應該講所有HTTP連接重定向到HTTP連接。

如果你將SECURE_SSL_REDIRECT設置為True，SecurityMiddleware會將HTTP鏈接永久地（HTTP 301，permanently）重定向到HTTPS連接。

注意

由于性能因素，最好在Django外面執(zhí)行這些重定向，在nginx這種前端負載均衡器或者反向代理服務器中執(zhí)行。SECURE_SSL_REDIRECT專門為這種部署情況而設計，當這不可選擇的時候。

如果SECURE_SSL_HOST設置有一個值，所有重定向都會發(fā)到值中的主機，而不是原始的請求主機。

如果你站點上的一些頁面應該以HTTP方式提供，并且不需要重定向到HTTPS，你可以SECURE_REDIRECT_EXEMPT設置中列出匹配那些url的正則表達式。

注意

如果你在負載均衡器或者反向代理服務器后面部署應用，而且Django不能辨別出什么時候一個請求是安全的，你可能需要設置SECURE_PROXY_SSL_HEADER。

會話中間件

class SessionMiddleware[source]

開啟會話支持。詳見會話文檔。

站點中間件

class CurrentSiteMiddleware[source]

Django 1.7中新增

向每個接收到的HttpRequest對象添加一個site屬性，表示當前的站點。詳見站點文檔。

認證中間件

class AuthenticationMiddleware[source]

向每個接收到的HttpRequest對象添加user屬性，表示當前登錄的用戶。詳見web請求中的認證。

class RemoteUserMiddleware[source]

使用web服務器提供認證的中間件。詳見使用REMOTE_USER進行認證。

class SessionAuthenticationMiddleware[source]

Django 1.7中新增

當用戶修改密碼的時候使用戶的會話失效。詳見密碼更改時的會話失效。在MIDDLEWARE_CLASSES中，這個中間件必須出現(xiàn)在django.contrib.auth.middleware.AuthenticationMiddleware之后。

CSRF保護中間件

class CsrfViewMiddleware[source]

添加跨站點請求偽造的保護，通過向POST表單添加一個隱藏的表單字段，并檢查請求中是否有正確的值。詳見CSRF保護文檔。

X-Frame-Options中間件

class XFrameOptionsMiddleware[source]

通過X-Frame-Options協(xié)議頭進行簡單的點擊劫持保護。

中間件的排序

下面是一些關(guān)于Django中間件排序的提示。

UpdateCacheMiddleware

放在修改大量協(xié)議頭的中間件(SessionMiddleware, GZipMiddleware, LocaleMiddleware)之前。

GZipMiddleware

放在任何可能修改或使用響應消息體的中間件之前。

放在UpdateCacheMiddleware之后：會修改大量的協(xié)議頭。

ConditionalGetMiddleware

放在CommonMiddleware之前：當USE_ETAGS = True時會使用它的Etag 協(xié)議頭。

SessionMiddleware

放在UpdateCacheMiddleware之后：會修改大量協(xié)議頭。

LocaleMiddleware

放在SessionMiddleware（由于使用會話數(shù)據(jù)）和 CacheMiddleware（由于要修改大量協(xié)議頭）之后的最上面。

CommonMiddleware

放在任何可能修改相應的中間件之前（因為它會生成ETags）。

在GZipMiddleware之后，不會在壓縮后的內(nèi)容上再去生成ETag。

盡可能放在靠上面的位置，因為APPEND_SLASH或者PREPEND_WWW設置為 True時會被重定向。

CsrfViewMiddleware

放在任何假設CSRF攻擊被處理的視圖中間件之前。

AuthenticationMiddleware

放在SessionMiddleware之后：因為它使用會話存儲。

MessageMiddleware

放在SessionMiddleware之后：會使用基于會話的存儲。

FetchFromCacheMiddleware

放在任何修改大量協(xié)議頭的中間件之后：協(xié)議頭被用來從緩存的哈希表中獲取值。

FlatpageFallbackMiddleware

應該放在最底下，因為他是中間件中的底牌。

RedirectFallbackMiddleware