Security issues in the 20:django

This section focuses on the security features in Django and tells you how Django is dealing with the security issues that the Web site typically faces.

Cross-site scripting (XXS) attacks

Cross-site scripting attacks refer to a user injecting client script into another user's browser. This is usually done by storing malicious scripts in the database, when those scripts are retrieved and then presented to other users, or by convincing the user to click on the attacker's script that will be run by the user's browser. How does Django deal with it?

Django's templating system can prevent most of the XXS attacks, but we need to know that Django prevents those, and those that are prevented: the Django template uses the "Escape special characters" method to escape characters that are dangerous to HTML, however, this is not permanent:

<classvar}}>... </ style >

What if the value of Var is Class1 onmouseover=javascript:func ()? Depends on how the browser handles this illegal HTML?

Therefore, when it is important to store HTML in the database, pay special attention to security, especially when these HTML will be retrieved and presented to the user!

Cross-site request forgery (CSRF) attack

A csrf attack is a user's credentials that are used by a malicious user to perform certain actions without the user's knowledge.

Django has built-in measures to prevent most types of csrf attacks, however, every precaution will have its own flaws, such as your site has some sub-sites that are not within your control.

Do not use the csrf_exemp adorner unless it is a last resort.

SQL injection Attacks

A SQL attack means that a malicious user can execute arbitrary SQL code on a database, which can result in data loss, deletion, or even crashing.

With Django's queryset, the resulting SQL will be correctly escaped by the underlying database driver. However, Django also provides developers to write native queries and run custom SQL, which are hidden dangers.

clickjacking Click Hijack

Have you ever encountered such a situation, open a Web page, a Flash ad box, you click the "Close" button, the results of the ads did not close, but turned into a full screen, such a situation in the Computer security field called Click Hijacking, that is, you click the mouse behavior is controlled by people. Django's x-frame-options middleware protects a site from being rendered as a frame (the HTML frame), preventing click Hijacking.

Therefore, any site that is not necessary to be encapsulated as a framework in a third-party site should enable this middleware.

Ssl/https

It's always better to be safe, though sometimes not practical. The main is not secure connection HTTPS, or there will be risks, whether the authentication credentials are intercepted or the client and the server side of the other information is converted, or other.

If you want to enable HTTPS, this is something extra to configure: (This configuration I have not implemented, for reference only, perhaps we can discuss privately when necessary)

• If necessary, set the Secure_proxy_ssl_header
• Set redirection to facilitate HTTP to go to HTTPS
• Using a secure cookie

Host Header Verification

In some cases, Django uses the host header to construct URLs that are safe under XXS attacks, but not necessarily when it comes to csrf, cache poisoning, poison chaining, and so on.

Because of these seemingly secure servers, there is a suspicion of disguising the head. Django validates a host header by contrasting allowed_host and Django.http.HttpRequest.get_host (), remembering that the only Get_host method is safe if you only use request. Meta content to verify the host header, you've put Django security in the

Other security issues

Although Django provides a lot of security measures, it is also important to develop your own applications and use Web servers, operating systems, and other components:

• Make sure your Python code is not in the root directory of your Web server, which ensures that your Python code is not accidentally executed
• Be careful with "user uploaded files"
• Django does not restrict requests to authenticate users, so to avoid a brute-force attack on the authentication system, you may need to develop a Django plug-in or Web server module to limit these requests
• If your site accepts file uploads, be sure to control these uploads to avoid denial-of-service attacks (DOS), such as controlling file size
• Don't reveal your secret_key.
• Restrict access to your cache and database by using a firewall

Security issues in the 20:django