iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 27
0
Modern Web

來個Django Web介面測試吧系列 第 27

來個Django Web介面測試吧:Day27-Django 安全性開發介紹

  • 分享至 

  • xImage
  •  

Django中的安全性

Django的安全功能包括有關保護Django驅動網站的建議。

跨站點腳本(XSS)保護

XSS攻擊使用戶可以將客戶端腳本註入其他用戶的瀏覽器中。通常,這是通過將惡意腳本存儲在數據庫中進行檢索並將其顯示給其他用戶,或者通過使用戶單擊鏈接來使攻擊者的JavaScript由用戶的瀏覽器執行來實現的。但是,只要未在包含在頁面中之前對數據進行足夠的清理,XSS攻擊就可能源自任何不受信任的數據源,例如cookie或Web服務。

使用Django模板可以保護您免受大多數XSS攻擊。但是,重要的是要瞭解其提供的保護及其限制。

Django模板會轉義特定字元 ,這對於HTML來說尤其危險。儘管這可以保護用戶免受大多數惡意輸入的侵害,但這並不是絕對安全的。例如,它將不會保護以下內容:

如果var將設置為,則可能導致未經授權的JavaScript執行,具體取決於瀏覽器如何呈現不完美的HTML。(引用屬性值將解決這種情況。)'class1 onmouseover=javascript:func()'

is_safe與自定義模板標籤,safe模板標籤一起使用mark_safe以及關閉自動轉義功能時,請務必特別小心。

此外,如果您使用模板系統輸出HTML以外的內容,則可能會有完全分開的字元和單詞需要轉義。

在數據庫中存儲HTML時,也應特別小心,尤其是在檢索和顯示HTML時。

跨站點請求偽造(CSRF)保護

CSRF攻擊允許惡意用戶使用另一用戶的憑據執行操作,而無需該用戶的知識或同意。

Django具有針對大多數CSRF攻擊的內置保護,只要您在適當的地方啟用和使用它即可。但是,與任何緩解技術一樣,存在局限性。例如,可以全局禁用或針對特定視圖禁用CSRF模塊。僅當您知道自己在做什麼時,才應該這樣做。如果您的站點具有您無法控制的子域,則還有其他限制。

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

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

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

SQL注入防護

SQL注入是一種攻擊,惡意用戶能夠在數據庫上執行任意SQL代碼。這可能導致記錄被刪除或數據洩漏。

由於Django的查詢集是使用查詢參數化構造的,因此可以防止SQL註入。查詢的SQL代碼是與查詢的參數分開定義的。由於參數可能是用戶提供的,因此是不安全的,因此底層數據庫驅動程式會對其進行轉義。

Django還使開發人員可以編寫原始查詢或執行自定義sql。這些功能應謹慎使用,並且您應始終小心謹慎地轉義用戶可以控制的任何參數。此外,使用extra() 和時應格外小心RawSQL。

點擊劫持保護

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

Django包含clickjacking保護,其形式為 在支持的瀏覽器中可以防止網站在框架內呈現。可以基於每個視圖禁用保護或配置發送的確切報頭值。X-Frame-Options middleware

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

SSL / HTTPS

在HTTPS後面部署站點對於安全性而言總是更好的選擇。否則,惡意網路用戶可能會嗅探身份驗證憑據或客戶端與服務器之間傳輸的任何其他信息,並且在某些情況下(活動的網路攻擊者)會更改沿任一方向發送的數據。

如果您想要HTTPS提供的保護並已在服務器上啟用了該保護,則可能需要執行一些其他步驟:

如有必要,請設置SECURE_PROXY_SSL_HEADER,以確保您已充分瞭解其中的警告。否則可能會導致CSRF漏洞,而如果不正確做則也很危險!

設置SECURE_SSL_REDIRECT為True,以便將通過HTTP的請求重定向到HTTPS。

請註意下的警告SECURE_PROXY_SSL_HEADER。對於反向代理,配置主Web服務器以重定向到HTTPS可能更容易或更安全。

使用“安全” cookie。

如果瀏覽器最初是通過HTTP連接(這是大多數瀏覽器的默認設置),則可能會洩漏現有的Cookie。因此,您應將SESSION_COOKIE_SECURE和 CSRF_COOKIE_SECURE設置設置為True。這指示瀏覽器僅通過HTTPS連接發送這些cookie。請註意,這將意味著會話將無法通過HTTP進行工作,並且CSRF保護將阻止通過HTTP接受任何POST數據(如果您將所有HTTP流量都重定向到HTTPS,這將很好)。

使用HTTP嚴格傳輸安全性(HSTS)

HSTS是一個HTTP標頭,它通知瀏覽器將來與特定站點的所有連接都應始終使用HTTPS。結合通過HTTP將請求重定向到HTTPS,這將確保只要發生一次成功的連接,連接就始終可以享受SSL的額外安全性。HSTS既可以與配置SECURE_HSTS_SECONDS, SECURE_HSTS_INCLUDE_SUBDOMAINS以及SECURE_HSTS_PRELOAD,或在Web服務器上。


上一篇
來個Django Web介面測試吧:Day26-Django 編寫可重用程式之3
下一篇
來個Django Web介面測試吧:Day28-Django 安全性開發介紹II
系列文
來個Django Web介面測試吧30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言