Web Vulnerabilities: Part 2 - Django
Hello Developers and Web Enthusiasts, welcome to the second part of our 4 part blog series on Web Vulnerabilities, and this time around we will be exploring Django! Let’s get started!
Introduction:
What is Django?
Django is a high-level python web framework that enables the rapid development of secure and maintainable websites. Django takes care of much of the hassle of web development, so it is easier for web developers to focus on writing the web app.
Since Django is written in python, which runs on various platforms, a web developer using Django need not worry about compatibility issues between various OSs like Linux, Mac and Windows. Also this makes collaboration between your friends or colleagues working on a project much more simpler than other platforms.
Now let’s look at a few popular web vulnerabilities and explore how you can handle them in a Django project.
1. XSS (Cross Site Scripting) Attack:
XSS is a term used to describe a class of attacks that allow an attacker to inject client-side scripts through the website into the browsers of other users. This is usually achieved by storing malicious scripts in the database where they can be retrieved and displayed to other users, or by getting users to click on a link that will cause the attacker’s JavaScript to be executed by the user’s browser.
The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.
The good news is that Django’s template system protects the application against the majority of XSS attacks by “escaping specific characters” that are considered dangerous in HTML.
What are these specific characters and why do we need to escape from them?
Let us consider a simple hello template in Django which renders out the name in the input field.
This seems harmless, but what if the user doesn’t enter a simple string and rather enters a harmful piece of code such as
This would give a pop-up JavaScript alert box in the browser where it shouldn’t!!!.
To avoid such type of inputs from the user we need to pass each of them through a escape filter which converts harmful HTML characters into innocent characters.
Now, if you are a Django user, you wouldn’t have to worry about this issue because Django by default provides HTML escaping in its templates.
For example:
< is converted to <
> is converted to >
‘ is converted to '
“ is converted to "
& is converted to &
2. Cross Site Request Forgery (CSRF):
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.
If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.
By default Django has a middle-ware setting which provides protection against CSRF attacks, this is done by including the {% csrf_token %} template tag in the form element of your HTML page.
This token is then rendered in your HTML as shown below, with a value that is specific to the user on the current browser.
Django generates a user/browser specific key and will reject forms that do not contain the field, or that contain an incorrect field value for the user/browser.
Also another safety measure to take care, is to add or set reasonable expiration dates to the cookies and access tokens, so even if the attacker manages to obtain a user’s cookie, there will be a limited time frame in which the attack can be carried out.
3. SQL Injection (SQLi):
SQL Injection is one of the most dangerous classes of web vulnerabilities. SQLi takes advantage of vulnerabilities in handling and processing of user input, which results in SQL code being executed in the server side and providing unauthorized access to the database, after which the intruder can view, modify, delete or even leak sensitive data.
Django being a modern framework is resilient to such attacks, but the use of Raw SQL queries to perform CRUD operations can open up an attack vector to exploit.
Thankfully Django has a way to protect developers from SQLi and that is by using the in-built ORM (Object-relational mapping) instead of raw SQL queries. Django ORM provides automatic query parameterization by separating the SQL query from the user input so that any malicious SQL code can be properly escaped and handled.
What is parameterization?
Parameterized queries or statements are a mechanism to pass dynamic parameters separate from the SQL query. These statements are interpreted directly by the database or safely escaped before being add to the actual SQL query.
Conclusion:
Although Django is resilient to almost all major web vulnerabilities, there is always a possibility of an exploit in a few functions, which is why you should always keep Django updated with the latest stable version released. Every Django release or patch update, increases the security of the app and fixes the bugs present in the previous versions, which is why is it very important to keep Django updated.
A modern web framework like Django protects the developer from the security risks described above. For issues like CSRF or XSS, it is easy to make the application vulnerable, however, in most cases the attacker would have to work actively have to disable or amend the standard behavior of the framework. Other vulnerabilities like SQL injections and privilege escalation — which for a long time have been amongst the most prevalent risks when it comes to web application security — are actually really hard to execute when using a modern web framework such as Django as the attacker has to actively work around the security functionality built into the framework.
Keep the above points in mind while working on your Django Project, as the functionality in your app is only good as the security of the app and you can’t compromise on security.
Hope you enjoyed reading this blog, stay tuned for the 3rd part of the blog series arriving soon!
