Merge pull request #331 from davidfischer/master

Ticket #17324 - Improve security docs with better CSRF explanation
This commit is contained in:
James Bennett 2012-09-07 12:02:53 -07:00
commit 257c4011cb
1 changed files with 26 additions and 6 deletions

View File

@ -76,9 +76,17 @@ POST to your Web site 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).
When deployed with :ref:`HTTPS <security-recommendation-ssl>`,
``CsrfViewMiddleware`` will check that the HTTP referer header is set to a
URL on the same origin (including subdomain and port). Because HTTPS
provides additional security, it is imperative to ensure connections use HTTPS
where it is available by forwarding insecure connection requests and using
HSTS for supported browsers.
Be very careful with marking views with the ``csrf_exempt`` decorator unless
it is absolutely necessary.
SQL injection protection
========================
@ -112,6 +120,8 @@ 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.
.. _security-recommendation-ssl:
SSL/HTTPS
=========
@ -147,7 +157,15 @@ server, there are some additional steps you may need:
any POST data being accepted over HTTP (which will be fine if you are
redirecting all HTTP traffic to HTTPS).
.. _additional-security-topics:
* Use HTTP Strict Transport Security (HSTS)
HSTS is an HTTP header that informs a browser that all future connections
to a particular site should always use HTTPS. Combined with redirecting
requests over HTTP to HTTPS, this will ensure that connections always enjoy
the added security of SSL provided one successful connection has occurred.
HSTS is usually configured on the web server.
.. _host-headers-virtual-hosting:
Host headers and virtual hosting
================================
@ -158,15 +176,17 @@ Site Scripting attacks, they can be used for Cross-Site Request
Forgery and cache poisoning attacks in some circumstances. We
recommend you ensure your Web server is configured such that:
* It always validates incoming HTTP ``Host`` headers against the expected
host name.
* Disallows requests with no ``Host`` header.
* Is *not* configured with a catch-all virtual host that forwards requests
to a Django application.
* It always validates incoming HTTP ``Host`` headers against the expected
host name.
* Disallows requests with no ``Host`` header.
* Is *not* configured with a catch-all virtual host that forwards requests
to a Django application.
Additionally, as of 1.3.1, Django requires you to explicitly enable support for
the ``X-Forwarded-Host`` header if your configuration requires it.
.. _additional-security-topics:
Additional security topics
==========================