Django's security mechanism

XSS Protection:

XSS attacks allow users to inject client script onto other users ' servers. Usually by storing malicious script to the database, other users to obtain malicious script through the database and render it on the browser, or to make the user click will cause the attacker Javascirpt script on the User Client connection to achieve the purpose. But XSS attacks can occur at any untrusted source of data, such as cookies and Web service. XSS attacks can occur whenever data is not adequately disinfected within the page (sanitized).

Using a Django template will protect you from most XSS attacks, but it is important to understand what protection the template provides and its limitations.

The escape of the Django template is a special character that is dangerous for HTML. Although this protects the user from most malicious input, it is not completely secure. For example, the following is not protected:

<styleclass={{var}}>...</style>

If Var is assigned a ' class1onmouseover=javascript:func () ' value, this results in unauthorized JavaScript execution, depending on how the browser renders the unfinished (imperfect) HTML

When used with Is_safe and custom tags (using Is_safe with custom template tags), extra care is important.

In addition, if you use a template to output non-HTML content, completely separate characters and words need to be escaped. You should also be careful when storing HTML into a database, especially when HTML is loaded and displayed.

CSRF Protection:

CSRF attacks allow a malicious user to perform an action with a certificate that is not known or allowed by another user.

Django has built up a lot of protection against most csrf attacks, if you've already opened and used them in the right place. However, there are limitations like other mitigation techniques. For example, it is possible to disable the CSRF module globally or for some specific views. You can do this only if you understand what you are doing. If your site has sub-domains outside of your control, there are also other restrictions.

CSRF protection works by detecting the random number of each POST request. This ensures that a malicious user cannot simply replay the post content of a form on your site and let other users who are already logged in unknowingly submit that form. A malicious user needs to know the random number, and this random number is for a specific user (with a cookie)

When deployed with HTTPS, Csrfviewmiddleware will check that the HTTP Referer header is set to the URL of the homologous domain (including subdomains and ports). Because HTTPS provides additional security, it is necessary to forward unsecured connection requests and to make sure that the connection is HTTPS with a browser that supports HSTs.

Be very careful to decorate the view with the csrf_exempt adorner, unless it is absolutely necessary.

SQL Input Protection:

SQL injection is a malicious user who is able to execute arbitrary SQL statements in the database. This can cause records to be deleted or data to be compromised.

With Django Queryset, the synthesized (resulting) SQL is properly escaped based on the database driver. Django, however, also gives developers the right to write original queries or custom SQL. These abilities should be used conservatively. You should always be careful to properly escape any parameters that the user can control. In addition, when using extra () you should be more cautious (exercise caution)

Click Hijack Protection:

Click Hijack is an attack of a malicious site that surrounds a frame in another site. This attack can result in unsuspecting users being tricked into performing unexpected behavior on the target site.

Django includes click-Hijacking protection in the X-frame-options middleware form, which protects the site from being rendered in a Frame in a supported browser. You can disable this protection on the basis of view, or configure send a clear header.

It is highly recommended that you use this middleware for websites that do not need or only allow a small subset of pages to be wrapped in third-party frames.

Ssl/https:

For security reasons, it is always better to deploy your website as HTTPS, although not all cases apply. Without HTTPS, malicious users sniff for authentication information, or other information that is transferred between the client and the server. In some cases, an active attacker would change the data transmitted by either party.

If you want to turn on HTTP on your server, you need to do the extra steps:

1. If necessary, set Secure_proxy_ssl_header to make sure you thoroughly understand the warning. Failure to do so can lead to csrf vulnerabilities, which can also be dangerous if not implemented correctly.

2, set up a jump, HTTP-based connections will jump to HTTPS.

This can be done with a custom middleware. Please note the warning of Secure_proxy_ssl_header. For cases with reverse jumps, it is easier and more secure to configure the primary Web server to jump to HTTPS

3. Use of safe cookies

If the browser uses the default HTTP connection, the cookie will be compromised. So you need your session_cookie_secure and csrf_cookie_secure set to true. This will allow the browser to send cookies only over HTTPS. Note that the session does not work under HTTP, and the CSRF protection mechanism blocks all post data that is transmitted over HTTP.

4, with HSTS (HTTP Strict Transport Security)

HSTs is an HTTP header that notifies the browser that all future connections to a site are https. By combining a jump to a request from HTTP to HTTPS, it ensures that a successful connection can always use SSL-provided security. HSTs are typically deployed on the server.

Master Header Confirmation

In some cases, Django uses the host header provided by the client to build the URL. Although these values are filtered to organize XSS attacks, false host values may be used to implement CSRF, cache poison attacks, and mail connection poisoning.

Because the seemingly secure server configuration is susceptible to spurious host header spoofing, Django confirms in the Httprequest.get_host () method that the host header is in conflict with the value set by the allowed_hosts.

Confirmation is only applied by the Get_host () method. If your code passes the request. Meta direct access to the host header, you will bypass this security guard.

For more information, please refer to the allowed_hosts section.

In addition, the 1.3.1 version of Django requires you to explicitly turn on support for the X-forwarded-host header if your configuration requires it.

Session security:

As with CSRF limitations, the need for special configuration of the site so that untrusted users do not have access to the subdomain, Django.contrib.sessions also has limitations. For more information, refer to Session topic Guide on security.

User Upload content:

If your site supports uploading, it is strongly recommended that you configure the limit upload file size to a reasonable extent to prevent denial of service attacks. Under Apache, it is easy to do it with limitrequestbody instructions.

If you manage your static files yourself, be sure to turn off processors like Apache's mod_php, which will execute static files as code. You certainly do not want users to execute arbitrary code by uploading or requesting a specially crafted file.

When the media does not follow the best practices for security, Django media file uploads can cause some vulnerabilities. In particular, an HTML file is uploaded as a file if the file contains a PNG header followed by malicious HTML code. This file is checked by the Django Image processing library. When this file is then displayed to the user, it will be rendered as HTML depending on the type and configuration of your server.

At the framework level there is no bulletproof verification that all users upload a technical solution exists. But there are a few steps you can take to reduce this attack.

A class of attacks can be prevented by serve users from a unique top-level or two-level domain name. Because of the protection of homologous policies, the use of XSS is blocked. For example, if your site is on example.com, you can map users ' uploaded files to usercontent-example.com. Mapping to usercontent.example.com is not enough.

The app can also optionally define a whitelist that allows the user to upload a file with a specific extension.

Additional security Policy:

Although Django provides good out-of-the-box security protections. It is also necessary to properly deploy your application and take advantage of the security of the server operating system and other components

Make sure your Python code is outside the server root folder, which ensures that your code is not interpreted incorrectly as plain text (or mistakenly executed)

Beware of files uploaded by users

Django does not restrict requests to authenticate users. To prevent brute-force damage to your authentication system, you may want to consider deploying a Django plug-in or Web server module to limit these requests.

Keep your Secret_key secret.

Restricting access to cache systems and databases with firewalls

Django's security mechanism