Django Web應用安全

寧靜致遠oj1kn5 2019-06-13

展開全文

保護用戶數(shù)據(jù)是任何網(wǎng)站設計的重要部分。我們之前在文章web安全中解釋了一些更常見的安全威脅--本文提供了Django的內(nèi)置保護如何處理這些威脅的實際演示。

前提:	閱讀服務器端網(wǎng)頁編程中的 "Website security" 主題。并請至少完成Django Web框架教程 Django Tutorial Part 9: 使用表單及以前的教程。
目標:	理解保障Django網(wǎng)站安全應該(和不應該)做的事情。

概述節(jié)

web安全主題提供一個概述，說明了網(wǎng)站安全對于服務器端設計的意義，以及以及一些需要應對的常見威脅。本文中包含一個關鍵的概念：如果網(wǎng)站信任任何來自瀏覽器的數(shù)據(jù)，幾乎所有的攻擊方法都會成功。

重要提示: 切記，對于網(wǎng)站安全來說最重要一點就是“永遠不要相信瀏覽器端提交的數(shù)據(jù)”。這些數(shù)據(jù)包括使用GET方式請求時URL中的參數(shù)，POST 方式請求的數(shù)據(jù)，HTTP headers 和 cookies，以及用戶上傳的文件等等. 請確保一定要檢查和清洗這些提交的數(shù)據(jù)。對于網(wǎng)站安全來說，總是要做好最壞的打算。

對Django用戶來說，好消息是Django框架已經(jīng)處理了大量的常見威脅。請閱讀Django官方文檔中的"Security in Django"部分來了解Django的安全細節(jié)，以及如何確?；贒jango的網(wǎng)站的安全。

常見威脅及保護節(jié)

在本文中，我們將使用前面章節(jié)中的“本地圖書館”項目作為示范來演示一些Django的安全特性。

跨站腳本 (XSS)節(jié)

XSS(英語：Cross site scripting，通常簡稱：XSS)是指一類惡意攻擊者將代碼通過網(wǎng)站注入到其他用戶瀏覽器中的攻擊方式。一般攻擊者會把惡意代碼作為普通數(shù)據(jù)放入到網(wǎng)站數(shù)據(jù)庫中，這樣其他用戶在獲取和展示數(shù)據(jù)的過程中就會受到攻擊。此外，攻擊者還可以通過引誘用戶點擊某些鏈接來執(zhí)行惡意的JavaScript代碼。

Django的模板系統(tǒng)可以幫您抵擋大部分的XSS攻擊，實現(xiàn)的方式在于轉(zhuǎn)義對于HTML來說比較“危險”的特殊字符(可參考官方文檔：escaping specific characters)?，F(xiàn)在，我們用Django Tutorial Part 9: Working with forms 這一章中的“創(chuàng)建作者”表單來做個演示，嘗試向我們的本地圖書館網(wǎng)站注入一些JavaScript腳本。

使用開發(fā)服務器啟動網(wǎng)站(參考命令：python3 manage.py runserver)。
在瀏覽器中打開網(wǎng)站，并用超級用戶身份登錄。
進入創(chuàng)建作者頁面 (地址可能會是：http://127.0.0.1:8000/catalog/author/create/)。
輸入姓名、生日等信息，隨后在Last Name這個字段里面填入以下的內(nèi)容：
<script>alert('Test alert');</script>

注意: 這一段代碼并沒有任何殺傷力，在執(zhí)行的時候只會在瀏覽器中彈出一個警告提示框。如果這個警告提示框出現(xiàn)，則表明本網(wǎng)站存在可被XSS攻擊的漏洞。
點擊 Submit 按鈕保存信息。
保存后的作者信息將會顯示為下圖的樣式。因為XSS防護措施的存在，注入代碼中的alert()部分并沒有執(zhí)行，而只是用文本的方式直接顯示了出來。

如果你有興趣閱讀下頁面的HTML源碼，則會發(fā)現(xiàn)危險的字符已被轉(zhuǎn)義成了無害的字符(例如： > 被轉(zhuǎn)義為了 > )

<h1>Author: Boon<script>alert('Test alert');</script>, David (Boonie) </h1>

Django的模板系統(tǒng)可以幫助抵御大部分的XSS攻擊。當然，XSS保護功能也可以被關閉，而且XSS保護一般對非用戶輸入的內(nèi)容不會自動進行防護(例如表單中字段的help_text通常不會是用戶提交的，所以這部分數(shù)據(jù)Django也不會進行轉(zhuǎn)義)

XSS攻擊也可能來自于其他不可信的數(shù)據(jù)來源，例如cookies，Web服務或上傳的文件（實際上只要是未經(jīng)清洗的數(shù)據(jù)直接展示出來都會有被攻擊的可能）。如果你要顯示這些不可信來源的數(shù)據(jù)，切記一定要自己做好數(shù)據(jù)清洗的工作。

防護跨站請求偽造 (CSRF) 節(jié)

CSRF(英語：Cross-site request forgery，通常簡稱：CSRF或XSRF)攻擊可以讓惡意攻擊者在用戶不知情的情況下，使用用戶的身份來進行系統(tǒng)操作。舉個例子，現(xiàn)在有一名黑客想要在我們的本地圖書館中添加一些作者信息。

注意：這個示例里面的黑客沒有考慮對錢下手。而現(xiàn)實生活中的黑客則極有可能會產(chǎn)生更加危險的操作（例如，把錢轉(zhuǎn)入他們自己的賬戶中等等）。

為了實現(xiàn)這個目的，黑客可以創(chuàng)建一個類似于下面示例的HTML文件，這個文件包含了一個創(chuàng)建作者的表單(類似我們在之前章節(jié)中用過的)，并且一旦加載完畢就會立即進行提交。隨后黑客可以將這個文件發(fā)送至所有的圖書管理員，并且引誘他們打開這個文件(文件中真的沒有啥有害的信息)。如果任何一個已登錄的圖書管理員不慎打開了這個文件，那么文件中的表單就會利用圖書管理員的身份來提交，隨后就會創(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>

運行Django開發(fā)服務器，然后使用超級管理員賬號進行登錄。將上面的代碼貼到一個文件中，并在瀏覽器中打開這個文件，隨后你就會看到一個CSRF錯誤，這是因為Django的安全機制防護了此類的攻擊。

在表單定義的時候加入 {% csrf_token %} 這個模板標簽， CSRF保護功能即可啟用。在模板渲染的時候，這個token在 HTML代碼中將會按照下面的格式顯示，包含了一個與當前用戶和當前瀏覽器關聯(lián)的值。

<input type='hidden' name='csrfmiddlewaretoken' value='0QRWHnYVg776y2l66mcvZqp8alrv4lb8S8lZ4ZJUWGZFA5VHrVfL2mpH29YZ39PW' />

Django生成這個用戶/瀏覽器關聯(lián)key的目的在于可以據(jù)此來拒絕那些不包含這個key的表單請求，也可以拒絕那些包含了錯誤了用戶/瀏覽器關聯(lián)key的表單請求。

有了這種保護機制后，攻擊者要發(fā)起攻擊就需要找到目標用戶的CSRF key。通過廣撒網(wǎng)給所有的圖書管理員發(fā)送惡意代碼文件的方式也很難奏效，因為CSRF key是和瀏覽器相關聯(lián)的。

Django的CSRF防御默認是開啟的。一定要在表單的位置使用 {% csrf_token %}這個標簽，同時，切記使用POST方式來發(fā)起新增和更新數(shù)據(jù)的請求。

其他防護措施節(jié)

Django還提供了很多其他形式的防護措施 (大部分不是很容易進行演示):

SQL注入防護: SQL注入漏洞可以讓攻擊者直接對網(wǎng)站數(shù)據(jù)庫執(zhí)行構造好的SQL語句，在無需用戶權限的情況下即可實現(xiàn)對數(shù)據(jù)的訪問、修改甚至是刪除。絕大多數(shù)的情況下，使用Django的查詢集/模型直接進行數(shù)據(jù)庫訪問時，實際使用的SQL語句已經(jīng)被底層的數(shù)據(jù)庫驅(qū)動妥善地進行了轉(zhuǎn)義。如果必須要直接執(zhí)行自定義的SQL語句，那么也請一定要注意防范SQL注入的問題。
點擊劫持防護: 點擊劫持是指攻擊者通過誘導用戶，用戶本意要訪問A網(wǎng)站，最終卻訪問到了B網(wǎng)站。舉例說明，攻擊者可以給用戶顯示一個合法的銀行網(wǎng)站，同時把用戶名密碼登錄框改為不可見的<iframe> 標簽，以此來竊取用戶的登錄信息。Django通過 X-Frame-Options中間件來防御點擊劫持攻擊，在支持的瀏覽器中，這種方式可以避免網(wǎng)站在iframe中顯示。
強制SSL/HTTPS: web服務器可通過啟用SSL/HTTPS來加密網(wǎng)站和瀏覽器之間的所有通信流量，包括了身份認證及其他通過純文本方式來發(fā)送的數(shù)據(jù)流量(強烈建議啟用HTTPS)。如果HTTPS已啟用，Django還提供了一起實用的保護措施:

SECURE_PROXY_SSL_HEADER 設置可以用于檢查內(nèi)容是否安全，可用于代理和Django之間使用非HTTPS方式通訊的情況下。
SECURE_SSL_REDIRECT 可以將所有HTTP的請求重定向到HTTPS。
使用 HTTP Strict Transport Security (HSTS) 頭來通知瀏覽器未來與此網(wǎng)站的連接僅使用HTTPS。與HTTP連接重定向至HTTPS的配置相結(jié)合后，HSTS可以確保之后的連接強制使用HTTPS。HSTS還有 SECURE_HSTS_SECOND和 SECURE_HSTS_INCLUDE_SUBDOMAINS 等選項可以進行配置。
將 SESSION_COOKIE_SECURE 和 CSRF_COOKIE_SECURE 設置為 True。這些配置將確保session和csrf的cookie僅使用HTTPS連接來發(fā)送。