|
|
|
|
@ -0,0 +1,168 @@
|
|
|
|
|
====================
|
|
|
|
|
Security in Django
|
|
|
|
|
====================
|
|
|
|
|
|
|
|
|
|
This document will show you the security features of Django as well
|
|
|
|
|
as give some advice about securing a Django site.
|
|
|
|
|
|
|
|
|
|
.. _cross-site-scripting:
|
|
|
|
|
|
|
|
|
|
Cross site scripting (XSS) protection
|
|
|
|
|
=====================================
|
|
|
|
|
|
|
|
|
|
.. highlightlang:: html+django
|
|
|
|
|
|
|
|
|
|
XSS attacks allow a user to inject client side scripts into the
|
|
|
|
|
browsers of other users. This is usually acheived by storing the malicious
|
|
|
|
|
scripts to the database where it will be retrieved and displayed to other users
|
|
|
|
|
or to get users to click a link containing variables containing scripts that
|
|
|
|
|
will be rendered by the user's browser. However, XSS attacks can originate
|
|
|
|
|
from any untrusted source of data such as cookies or web services.
|
|
|
|
|
|
|
|
|
|
Using Django templates protects you against the majority of XSS attacks.
|
|
|
|
|
However, it is important to understand what protections it provides
|
|
|
|
|
and its limitations.
|
|
|
|
|
|
|
|
|
|
Django templates :ref:`escape specific characters <automatic-html-escaping>`
|
|
|
|
|
which are particularly dangerous to HTML. While this protects users from most
|
|
|
|
|
malications input, it is not entirely foolproof. For example, it will not
|
|
|
|
|
protect the following:
|
|
|
|
|
|
|
|
|
|
.. code-block:: html+django
|
|
|
|
|
|
|
|
|
|
<style class={{ var }}>...</style>
|
|
|
|
|
|
|
|
|
|
If ``var`` is set to ``'class1 onmouseover=javascript:func()'``, this can result
|
|
|
|
|
in unauthorized javascript execution depending on how the browser renders
|
|
|
|
|
imperfect HTML.
|
|
|
|
|
|
|
|
|
|
It is also important to be particularly careful when using ``is_safe`` with
|
|
|
|
|
custom template tags, the :ttag:`safe` template tag, :mod:`mark_safe
|
|
|
|
|
<django.utils.safestring>`, and when autoescape is turned off.
|
|
|
|
|
|
|
|
|
|
In addition, if you are using the template system to output something other
|
|
|
|
|
than HTML, there may be entirely separate characters and words which require
|
|
|
|
|
escaping.
|
|
|
|
|
|
|
|
|
|
You should also be very careful when storing HTML to the database especially
|
|
|
|
|
when that HTML will be retrieved and displayed.
|
|
|
|
|
|
|
|
|
|
Cross site request forgery (CSRF) protection
|
|
|
|
|
============================================
|
|
|
|
|
|
|
|
|
|
CSRF attacks allow a malicious user to execute actions using the credentials
|
|
|
|
|
of another user without that user's knowledge or consent.
|
|
|
|
|
|
|
|
|
|
Django has built-in protection against most types of CSRF attacks, providing you
|
|
|
|
|
have :ref:`enabled and used it <using-csrf>` where appropriate. However, as with
|
|
|
|
|
any mitigation technique, there are limitations. For example, it is possible to
|
|
|
|
|
disable the CSRF module globally or for particular views. You should only do
|
|
|
|
|
this if you know what you are doing. There are other :ref:`limitations
|
|
|
|
|
<csrf-limitations>` if your site has subdomains that are outside of your
|
|
|
|
|
control.
|
|
|
|
|
|
|
|
|
|
:ref:`CSRF protection works <how-csrf-works>` by checking for a nonce in each
|
|
|
|
|
POST request. This ensures that a malicious user cannot simply "replay" a form
|
|
|
|
|
POST to your website and have another logged in user unwittingly submit that
|
|
|
|
|
form. The malicious user would have to know the nonce, which is user specific
|
|
|
|
|
(using a cookie).
|
|
|
|
|
|
|
|
|
|
Be very careful with marking views with the ``csrf_exempt`` decorator unless
|
|
|
|
|
it is absolutely necessary.
|
|
|
|
|
|
|
|
|
|
SQL injection protection
|
|
|
|
|
========================
|
|
|
|
|
|
|
|
|
|
SQL injection is a type of attack where a malicious user is able to execute
|
|
|
|
|
arbitrary SQL code on a database. This can result in records
|
|
|
|
|
being deleted or data leakage.
|
|
|
|
|
|
|
|
|
|
By using Django's querysets, the resulting SQL will be properly escaped by
|
|
|
|
|
the underlying database driver. However, Django also gives developers power to
|
|
|
|
|
write :ref:`raw queries <executing-raw-queries>` or execute
|
|
|
|
|
:ref:`custom sql <executing-custom-sql>`. These capabilities should be used
|
|
|
|
|
sparingly and you should always be careful to properly escape any parameters
|
|
|
|
|
that the user can control. In addition, you should exercise caution when using
|
|
|
|
|
:meth:`extra() <django.db.models.query.QuerySet.extra>`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Clickjacking protection
|
|
|
|
|
=======================
|
|
|
|
|
|
|
|
|
|
Clickjacking is a type of attack where a malicious site wraps another site
|
|
|
|
|
in a frame. This attack can result in an unsuspecting user being tricked
|
|
|
|
|
into performing unintended actions on the target site.
|
|
|
|
|
|
|
|
|
|
Django contains :ref:`clickjacking protection <clickjacking-prevention>` in
|
|
|
|
|
the form of the
|
|
|
|
|
:mod:`X-Frame-Options middleware <django.middleware.clickjacking.XFrameOptionsMiddleware>`
|
|
|
|
|
which in a supporting browser can prevent a site from being rendered inside
|
|
|
|
|
of a frame. It is possible to disable the protection on a per view basis
|
|
|
|
|
or to configure the exact header value sent.
|
|
|
|
|
|
|
|
|
|
The middleware is strongly recommended for any site that does not need to have
|
|
|
|
|
its pages wrapped in a frame by third party sites, or only needs to allow that
|
|
|
|
|
for a small section of the site.
|
|
|
|
|
|
|
|
|
|
SSL/HTTPS
|
|
|
|
|
=========
|
|
|
|
|
|
|
|
|
|
It is always better for security, though not always practical in all cases, to
|
|
|
|
|
deploy your site behind HTTPS. Without this, it is possible for malicious
|
|
|
|
|
network users to sniff authentication credentials or any other information
|
|
|
|
|
transferred between client and server, and in some cases - **active** network
|
|
|
|
|
attackers - to alter data that is sent in either direction.
|
|
|
|
|
|
|
|
|
|
If you want the protection that HTTPS provides, and have enabled it on your
|
|
|
|
|
server, there are some additional steps to consider to ensure that sensitive
|
|
|
|
|
information is not leaked:
|
|
|
|
|
|
|
|
|
|
* Set up redirection so that requests over HTTP are redirected to HTTPS.
|
|
|
|
|
|
|
|
|
|
It is possible to do this with a piece of Django middleware. However, this has
|
|
|
|
|
problems for the common case of a Django app running behind a reverse
|
|
|
|
|
proxy. Often, reverse proxies are configured to set the ``X-Forwarded-SSL``
|
|
|
|
|
header (or equivalent) if the incoming connection was HTTPS, and the absence
|
|
|
|
|
of this header could be used to detect a request that was not HTTPS. However,
|
|
|
|
|
this method usually cannot be relied on, as a client, or a malicious active
|
|
|
|
|
network attacker, could also set this header.
|
|
|
|
|
|
|
|
|
|
So, for the case of a reverse proxy, it is recommended that the main web
|
|
|
|
|
server should be configured to do the redirect to HTTPS, or configured to send
|
|
|
|
|
HTTP requests to an app that unconditionally redirects to HTTPS.
|
|
|
|
|
|
|
|
|
|
* Use 'secure' cookies.
|
|
|
|
|
|
|
|
|
|
If a browser connects initially via HTTP, which is the default for most
|
|
|
|
|
browsers, it is possible for existing cookies to be leaked. For this reason,
|
|
|
|
|
you should set your :setting:`SESSION_COOKIE_SECURE` and
|
|
|
|
|
:setting:`CSRF_COOKIE_SECURE` settings to ``True``. This instructs the browser
|
|
|
|
|
to only send these cookies over HTTPS connections. Note that this will mean
|
|
|
|
|
that sessions will not work over HTTP, and the CSRF protection will prevent
|
|
|
|
|
any data POST data being accepted over HTTP (which will be fine if you are
|
|
|
|
|
redirecting all HTTP traffic to HTTPS).
|
|
|
|
|
|
|
|
|
|
.. _additional-security-topics:
|
|
|
|
|
|
|
|
|
|
Additional security topics
|
|
|
|
|
==========================
|
|
|
|
|
|
|
|
|
|
While Django provides good security protection out of the box, it is still
|
|
|
|
|
important to properly deploy your application and take advantage of the
|
|
|
|
|
security protection of the web server, operating system and other components.
|
|
|
|
|
|
|
|
|
|
* Make sure that your Python code is outside of the web server's root. This
|
|
|
|
|
will ensure that your Python code is not accidentally served as plain text.
|
|
|
|
|
* Django does not throttle requests to authenticate users. To protect against
|
|
|
|
|
brute-force attacks against the authentication system, you may consider
|
|
|
|
|
deploying a Django plugin or web server module to throttle these requests.
|
|
|
|
|
* If your site accepts file uploads, it is strongly advised that you limit
|
|
|
|
|
the these uploads in your web server configuration to a reasonable
|
|
|
|
|
size in order to prevent denial of service (DOS) attacks. In Apache, this
|
|
|
|
|
can be easily set using the LimitRequestBody_ directive.
|
|
|
|
|
* Keep your :setting:`SECRET_KEY` a secret.
|
|
|
|
|
* It is a good idea to limit the accessibility of your caching system and
|
|
|
|
|
database using a firewall.
|
|
|
|
|
|
|
|
|
|
.. _LimitRequestBody: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestbody
|
|
|
|
|
|
Luke Plant