Django web application security

2018-05-15 17:26 更新
先決條件: 閱讀服務(wù)器端程序"網(wǎng)站安全"主題。 完成Django教程主題(至少包括)至少 Django教程第9部分:使用表單。
目的: 理解你需要做（或不做）的主要事情來保護你的Django Web應(yīng)用程序。

概述

網(wǎng)站安全主題概述了網(wǎng)站安全對于服務(wù)器端設(shè)計的意義，以及一些 的你可能需要防范的更常見的威脅。 該文章中的一個關(guān)鍵消息是，當Web應(yīng)用程序信任來自瀏覽器的數(shù)據(jù)時，幾乎所有攻擊都成功。

重要信息:您可以了解有關(guān)網(wǎng)站安全性的最重要的一個教訓是不要信任來自瀏覽器的數(shù)據(jù)。 這包括網(wǎng)址參數(shù)， POST 數(shù)據(jù)，HTTP標頭和Cookie，用戶上傳的文件等中的 GET 請求數(shù)據(jù)。始終檢查和清理所有傳入的數(shù)據(jù)。 總是假設(shè)最壞的。

Django用戶的好消息是，許多更常見的威脅都由框架處理！ Django中的安全性(Django docs)文章介紹了Django的安全功能以及如何 保護Django驅(qū)動的網(wǎng)站。

常見的威脅/保護

在本文中，我們將僅演示在我們的Django LocalLibrary 教程中的一些安全功能，而不是復制Django文檔。

跨站腳本(XSS)

XSS是用于描述允許攻擊者通過網(wǎng)站將客戶端腳本注入到其他用戶的瀏覽器中的一類攻擊的術(shù)語。 這通常通過在數(shù)據(jù)庫中存儲惡意腳本來實現(xiàn)，其中可以將惡意腳本檢索并顯示給其他用戶，或者通過讓用戶單擊將導致攻擊者的JavaScript由用戶的瀏覽器執(zhí)行的鏈接。

Django的模板系統(tǒng)通過保護您免受大多數(shù)XSS攻擊 轉(zhuǎn)義在HTML中為"危險"的特定字符。 我們可以通過嘗試使用我們在 Django教程第9部分:使用表單中設(shè)置的創(chuàng)建作者表單將一些JavaScript注入我們的LocalLibrary網(wǎng)站來演示。

  1. Start the website using the development server (python3 manage.py runserver).
  2. Open the site in your local browser and login to your superuser account.
  3. Navigate to the author-creation page (which should be at URL: http://127.0.0.1:8000/catalog/author/create/).
  4. Enter names and date details for a new user, and then append the following text to the Last Name field:
    <script>alert('Test alert');</script>.

    注意:這是一個無害的腳本，如果執(zhí)行，會在瀏覽器中顯示一個警告框。 如果在提交記錄時顯示警報，則該站點容易受到XSS威脅。

  5. Press Submit to save the record.
  6. When you save the author it will be displayed as shown below. Because of the XSS protections the alert() should not be run. Instead the script is displayed as plain text.

如果你查看頁面的HTML源代碼，你可以看到腳本標簽的危險字符已經(jīng)變成了它們無害的轉(zhuǎn)義碼等價物(例如> 現(xiàn)在& gt; / code>)

<h1>Author: Boon&lt;script&gt;alert(&#39;Test alert&#39;);&lt;/script&gt;, David (Boonie) </h1>

使用Django模板保護您免受大多數(shù)XSS攻擊。 但是，可以關(guān)閉此保護，并且保護不會自動應(yīng)用于通常不會由用戶輸入填充的所有標記(例如，表單字段中的 help_text 通常 不是用戶提供的，所以Django不會轉(zhuǎn)義那些值)。

XSS攻擊也可能來自其他不受信任的數(shù)據(jù)源，例如Cookie，Web服務(wù)或上傳的文件(只要數(shù)據(jù)在包含在頁面中之前未被充分清理)。 如果您要顯示來自這些來源的數(shù)據(jù)，那么您可能需要添加自己的驗證碼。

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

CSRF攻擊允許惡意用戶在沒有該用戶的知識或同意的情況下使用另一用戶的憑證來執(zhí)行動作。 例如，假設(shè)我們有一個黑客想為我們的LocalLibrary創(chuàng)建其他作者。

注意:顯然，我們的黑客不是為了這筆錢！ 一個更有野心的黑客可以在其他網(wǎng)站上使用相同的方法來執(zhí)行更加有害的任務(wù)(例如將錢轉(zhuǎn)到自己的帳戶等)

為了做到這一點，他們可能創(chuàng)建一個HTML文件，如下所示，它包含一個作者創(chuàng)建表單(就像我們在上一節(jié)中使用的)，一旦文件加載提交。 然后他們將文件發(fā)送給所有的圖書館員，并建議他們打開文件(它包含一些無害的信息，誠實！)。 如果文件由任何已登錄的庫管理器打開，則將使用其憑據(jù)提交表單，并創(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>

運行開發(fā)Web服務(wù)器，并使用超級用戶帳戶登錄。 將上面的文本復制到一個文件，然后在瀏覽器中打開它。 你應(yīng)該得到一個CSRF錯誤，因為Django有這種事情的保護！

啟用保護的方式是在表單定義中包含 {％csrf_token％} 模板標記。 然后，此標記將顯示在您的HTML中，如下所示，其中的值特定于當前瀏覽器上的用戶。

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

Django生成用戶/瀏覽器特定的鍵，并將拒絕不包含該字段或包含用戶/瀏覽器的不正確字段值的表單。

為了使用這種類型的攻擊，黑客現(xiàn)在必須發(fā)現(xiàn)并包括用于特定目標用戶的CSRF密鑰。 他們也不能使用"scattergun"方法向所有庫管理員發(fā)送惡意文件，并希望其中一個將打開它，因為CSRF密鑰是特定于瀏覽器的。

默認情況下，Django的CSRF保護功能處于打開狀態(tài)。 您應(yīng)該始終使用表單中的 {％csrf_token％} 模板標記，并對可能更改或向數(shù)據(jù)庫添加數(shù)據(jù)的請求使用 POST 。

其他保護

Django還提供其他形式的保護(大多數(shù)是困難的或不特別有用的演示):

SQL injection protection
SQL injection vulnerabilities enable malicious users to execute arbitrary SQL code on a database, allowing data to be accessed, modified, or deleted irrespective of the user's permissions. In almost every case you'll be accessing the database using Django’s querysets/models, so the resulting SQL will be properly escaped by the underlying database driver. If you do need to write raw queries or custom SQL then you'll need to explicitly think about preventing SQL injection.
Clickjacking protection
In this attack a malicious user hijacks clicks meant for a visible top level site and routes them to a hidden page beneath. This technique might be used, for example, to display a legitimate bank site but capture the login credentials in an invisible <iframe> controlled by the attacker. Django contains clickjacking protection in the form of the X-Frame-Options middleware which, in a supporting browser, can prevent a site from being rendered inside a frame.
Enforcing SSL/HTTPS
SSL/HTTPS can be enabled on the web server in order to encrypt all traffic between the site and browser, including authentication credentials that would otherwise be sent in plain text (enabling HTTPS is highly recommended). If HTTPS is enabled then Django provides a number of other protections you can use:
Host header validation
Use ALLOWED_HOSTS to only accept requests from trusted hosts.

還有許多其他保護，并注意到使用上述機制。 雖然我們希望這給了你Django提供的概述，你應(yīng)該仍然閱讀Django安全文檔。

    概要

    Django有針對一些常見威脅的有效保護，包括XSS和CSRF攻擊。 在本文中，我們已經(jīng)在我們的 LocalLibrary 網(wǎng)站中演示了Django如何處理這些特定威脅。 我們還提供了一些其他保護的簡要概述。

    這是一個非常簡短的web安全。 我們強烈建議您閱讀 Django中的安全性，以獲得更深入的了解。

    本單元中關(guān)于Django的下一步和最后一步是完成評估任務(wù)。

    也可以看看

    以上內(nèi)容是否對您有幫助：
    在線筆記
    App下載
    App下載

    掃描二維碼

    下載編程獅App

    公眾號
    微信公眾號

    編程獅公眾號