Fixed #17101 -- Integrated django-secure and added check --deploy option

Thanks Carl Meyer for django-secure and for reviewing.

Thanks also to Zach Borboa, Erik Romijn, Collin Anderson, and
Jorge Carleitao for reviews.

docs/ref/middleware.txt

@@ -155,6 +155,178 @@ Message middleware
 Enables cookie- and session-based message support. See the
 :doc:`messages documentation </ref/contrib/messages>`.
 
+.. _security-middleware:
+
+Security middleware
+-------------------
+
+.. module:: django.middleware.security
+    :synopsis: Security middleware.
+
+.. warning::
+    If your deployment situation allows, it's usually a good idea to have your
+    front-end Web server perform the functionality provided by the
+    ``SecurityMiddleware``. That way, if there are requests that aren't served
+    by Django (such as static media or user-uploaded files), they will have
+    the same protections as requests to your Django application.
+
+.. class:: SecurityMiddleware
+
+.. versionadded:: 1.8
+
+The ``django.middleware.security.SecurityMiddleware`` provides several security
+enhancements to the request/response cycle. Each one can be independently
+enabled or disabled with a setting.
+
+* :setting:`SECURE_BROWSER_XSS_FILTER`
+* :setting:`SECURE_CONTENT_TYPE_NOSNIFF`
+* :setting:`SECURE_HSTS_INCLUDE_SUBDOMAINS`
+* :setting:`SECURE_HSTS_SECONDS`
+* :setting:`SECURE_REDIRECT_EXEMPT`
+* :setting:`SECURE_SSL_HOST`
+* :setting:`SECURE_SSL_REDIRECT`
+
+.. _http-strict-transport-security:
+
+HTTP Strict Transport Security
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For sites that should only be accessed over HTTPS, you can instruct modern
+browsers to refuse to connect to your domain name via an insecure connection
+(for a given period of time) by setting the `"Strict-Transport-Security"
+header`_. This reduces your exposure to some SSL-stripping man-in-the-middle
+(MITM) attacks.
+
+``SecurityMiddleware`` will set this header for you on all HTTPS responses if
+you set the :setting:`SECURE_HSTS_SECONDS` setting to a non-zero integer value.
+
+When enabling HSTS, it's a good idea to first use a small value for testing,
+for example, :setting:`SECURE_HSTS_SECONDS = 3600<SECURE_HSTS_SECONDS>` for one
+hour. Each time a Web browser sees the HSTS header from your site, it will
+refuse to communicate non-securely (using HTTP) with your domain for the given
+period of time. Once you confirm that all assets are served securely on your
+site (i.e. HSTS didn't break anything), it's a good idea to increase this value
+so that infrequent visitors will be protected (31536000 seconds, i.e. 1 year,
+is common).
+
+Additionally, if you set the :setting:`SECURE_HSTS_INCLUDE_SUBDOMAINS` setting
+to ``True``, ``SecurityMiddleware`` will add the ``includeSubDomains`` tag to
+the ``Strict-Transport-Security`` header. This is recommended (assuming all
+subdomains are served exclusively using HTTPS), otherwise your site may still
+be vulnerable via an insecure connection to a subdomain.
+
+.. warning::
+    The HSTS policy applies to your entire domain, not just the URL of the
+    response that you set the header on. Therefore, you should only use it if
+    your entire domain is served via HTTPS only.
+
+    Browsers properly respecting the HSTS header will refuse to allow users to
+    bypass warnings and connect to a site with an expired, self-signed, or
+    otherwise invalid SSL certificate. If you use HSTS, make sure your
+    certificates are in good shape and stay that way!
+
+.. note::
+    If you are deployed behind a load-balancer or reverse-proxy server, and the
+    ``Strict-Transport-Security`` header is not being added to your responses,
+    it may be because Django doesn't realize that it's on a secure connection;
+    you may need to set the :setting:`SECURE_PROXY_SSL_HEADER` setting.
+
+.. _"Strict-Transport-Security" header: http://en.wikipedia.org/wiki/Strict_Transport_Security
+
+.. _x-content-type-options:
+
+``X-Content-Type-Options: nosniff``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Some browsers will try to guess the content types of the assets that they
+fetch, overriding the ``Content-Type`` header. While this can help display
+sites with improperly configured servers, it can also pose a security
+risk.
+
+If your site serves user-uploaded files, a malicious user could upload a
+specially-crafted file that would be interpreted as HTML or Javascript by
+the browser when you expected it to be something harmless.
+
+To learn more about this header and how the browser treats it, you can
+read about it on the `IE Security Blog`_.
+
+To prevent the browser from guessing the content type and force it to
+always use the type provided in the ``Content-Type`` header, you can pass
+the ``X-Content-Type-Options: nosniff`` header.  ``SecurityMiddleware`` will
+do this for all responses if the :setting:`SECURE_CONTENT_TYPE_NOSNIFF` setting
+is ``True``.
+
+Note that in most deployment situations where Django isn't involved in serving
+user-uploaded files, this setting won't help you. For example, if your
+:setting:`MEDIA_URL` is served directly by your front-end Web server (nginx,
+Apache, etc.) then you'd want to set this header there. On the other hand, if
+you are using Django to do something like require authorization in order to
+download files and you cannot set the header using your Web server, this
+setting will be useful.
+
+.. _IE Security Blog: http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx
+
+.. _x-xss-protection:
+
+``X-XSS-Protection: 1; mode=block``
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Some browsers have the ability to block content that appears to be an `XSS
+attack`_. They work by looking for Javascript content in the GET or POST
+parameters of a page. If the Javascript is replayed in the server's response,
+the page is blocked from rendering and an error page is shown instead.
+
+The `X-XSS-Protection header`_ is used to control the operation of the
+XSS filter.
+
+To enable the XSS filter in the browser, and force it to always block
+suspected XSS attacks, you can pass the ``X-XSS-Protection: 1; mode=block``
+header. ``SecurityMiddleware`` will do this for all responses if the
+:setting:`SECURE_BROWSER_XSS_FILTER` setting is ``True``.
+
+.. warning::
+    The browser XSS filter is a useful defense measure, but must not be
+    relied upon exclusively. It cannot detect all XSS attacks and not all
+    browsers support the header. Ensure you are still :ref:`validating and
+    sanitizing <cross-site-scripting>` all input to prevent XSS attacks.
+
+.. _XSS attack: http://en.wikipedia.org/wiki/Cross-site_scripting
+.. _X-XSS-Protection header: http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx
+
+.. _ssl-redirect:
+
+SSL Redirect
+~~~~~~~~~~~~
+
+If your site offers both HTTP and HTTPS connections, most users will end up
+with an unsecured connection by default. For best security, you should redirect
+all HTTP connections to HTTPS.
+
+If you set the :setting:`SECURE_SSL_REDIRECT` setting to True,
+``SecurityMiddleware`` will permanently (HTTP 301) redirect all HTTP
+connections to HTTPS.
+
+.. note::
+
+    For performance reasons, it's preferable to do these redirects outside of
+    Django, in a front-end load balancer or reverse-proxy server such as
+    `nginx`_. :setting:`SECURE_SSL_REDIRECT` is intended for the deployment
+    situations where this isn't an option.
+
+If the :setting:`SECURE_SSL_HOST` setting has a value, all redirects will be
+sent to that host instead of the originally-requested host.
+
+If there are a few pages on your site that should be available over HTTP, and
+not redirected to HTTPS, you can list regular expressions to match those URLs
+in the :setting:`SECURE_REDIRECT_EXEMPT` setting.
+
+.. note::
+    If you are deployed behind a load-balancer or reverse-proxy server and
+    Django can't seem to tell when a request actually is already secure, you
+    may need to set the :setting:`SECURE_PROXY_SSL_HEADER` setting.
+
+.. _nginx: http://nginx.org
+
 Session middleware
 ------------------