Make A Django App Insecure Is Not Easy

Is Django secure?

Anyway, None of the Internet systems are resistant to security threats. Security is just an illusion. Everything is breakable. If we talk about Django, it is incredible when it comes to building Python-based applications. As a fully-equipped, open-source toolkit with exceedingly customization design, it energizes fast improvement and straightforward code structure. So, It is very difficult to make a Django app insecure. As a matter of course, Django forestalls most regular security mistakes. We got to know about default Django security systems and take after certain best practices to build a secure web application.

If you wants your project must be secure from most common vulnerabilities and attacks by default. For example CSRF, SQL Injection, XSS, Click-jacking, etc and you want to use open source software, then try Django. In my opinion, Django is the perfect balance between performance, development effort, security and scalability.

Developers are sometimes very lazy. I am the one of the type :). I hesitate doing a few assignments which aren't pivotal for development. These assignments ordinarily open entryways for security vulnerabilities. The portion I like most, security features are empowered by default so it doesn't matter in the time when you are sluggish.

OWASP Top 10

The OWASP Top 10 Web Application Security Risks describes the foremost basic and most commonly happening security flaws in web applications. This list is published each three a long time. It was updated in 2017 to provide guidance to developers and security professionals on the most critical vulnerabilities that are commonly found in web applications, which are also easy to exploit.

1. Injection
2. Broken Authentication and Session Management
3. Sensitive Data Exposure
4. XML External Entity
5. Broken Access Control
6. Security Misconfiguration
7. Cross-Site Scripting
8. Insecure Deserialization
9. Using Components With Known Vulnerabilities
10. Insufficient Logging and Monitoring

Let's take some common security mistakes and how it prevented by Django.

Injection

Injection flaws, such as SQL injection, SQL injection is a code injection technique that might destroy your database. It is one of the most common web hacking techniques. This can result in records being deleted or data leakage. Django uses built-in ORM, so there is no risk of SQL injection, but raw queries are possible. You / developer should always be careful to properly escape any parameters that the user can control.

Broken Authentication and Session Management

It is always better for security to deploy your site behind HTTPS. HTTPS helps prevent intruders from tampering with the communications between your websites and your users' browsers. If you use 'secure' cookies or SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE settings to True, you can prevent cookies leakage. And Django provides some extra session securities.

Sensitive Data Exposure

Django uses the PBKDF2 algorithm with a SHA256 hash, a password stretching mechanism recommended by NIST. This should be sufficient for most users. It's quite secure, requiring massive amounts of computing time to break. Another type of data exposure is, If you set DEBUG = True in your project settings.py and deploy your project to production user can see your source code and local variables (hence you're leaking potentially sensitive data.

Cross-Site Scripting

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into websites. XSS attacks allow a user to inject client side scripts into the browsers of other users. Django template system by default escapes variables, unless they are explicitly marked as safe. However, it is important to understand what protections it provides and its limitations. Be very careful with marking views with the csrf_exempt decorator unless it is completely essential.

Cross site request forgery (CSRF)

Cross site request forgery (CSRF), also known as XSRF, Sea Surf or Session Riding, is an attack vector that traps a web browser into executing an undesirable activity in an application to which a user is logged in. If the victim is an administrative account, CSRF can compromise the entire web application. Django has built-in protection against most types of CSRF attacks, providing you have enabled and used it where appropriate. However, as with any mitigation technique, there are limitations (it is possible to disable the CSRF module globally or for particular views).

Click jacking

Click jacking Also known as a "UI redress attack", is when an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the the top level page by using iframes. It can detect when the content is requested from unauthorized iframe.

Regularly, clickjacking is performed by showing an invisible page or HTML element, inside an iframe, on best of the page the user sees suck as important forms. The user accepts they are clicking the obvious page but in truth they are clicking an invisible element within the extra page transposed on top of it. The middleware is strongly suggested for any site that does not have to be have its pages wrapped in a frame by third party sites.

Conclusion

So, Django has viable assurances against a number of common attacks, counting XSS and CSRF. In this article I illustrated how those specific attacks are deal with by Django described a few of the other security protections. It is really hard to make a Django project insecure.

If you want to learn to break the security of a Django application, try with django.nV. django.nV is a purposefully vulnerable application provided by nVisium. It demonstrates a series of common vulnerabilities in the context of a modern application. The flaws within the application include vulnerabilities ranging from the OWASP Top 10 (Injection, Insecure Direct Object Reference) to some Django-specific issues (Mass Assignment and Insecure Settings). To setup this, clone files from their GitHub repository.

In case you discover any mistakes, or feel any need for improvement, let me know in comments.

References

https://docs.djangoproject.com/en/3.0/topics/security/

https://www.owasp.org

https://nvisium.com/blog/2015/08/13/introducing-djangonv-intentionally.html