1 of 34

A Case Study of �Django ��Web Applications that are Secure by Default

Mohammed ALDOUB

@Voulnet

2 of 34

Web Security Essentials

The essentials of web application security are still not well understood.

Most developers have little to no idea about web security fundamentals.

Higher adoption to new web technologies, but no accompanying security awareness.

3 of 34

Web Security Essentials

The basic idea of web security: Never trust users, and never trust their data. No exceptions.

Many layers exist in web technologies, and therefore many attack vectors and possibilities.

Web developers must understand risks and mitigations for all web layers.

4 of 34

Problems in Applying Web Security

Web security cannot be achieved if developers are not well trained in security. Education is key.

Deadlines will almost always result in security vulnerabilities. Developers who are too busy and under pressure will not focus on security.

Security is not integrated early in the development process, so it gets delayed/forgotten.

5 of 34

Bad Practices in Web Security

Developers don’t validate user input.

Even if they validate it, they do it poorly or out of context.

Developers make wrong assumptions about security:

“It’s ok, we use SSL!”
“The Firewall will protect us”
“Who will think of attacking this function?”

Most developers copy/paste code from the internet. Admit it.

6 of 34

Bad Practices in Web Security

Session/password management is done poorly:

Sessions are easy to forge by attackers.
Passwords are stored as plaintext.

Server & Database configuration/security are not understood by web developers.

Developers don’t realize the threats on end users:

Cross Site Scripting (XSS)
Cross Site Request Forgery (CSRF)

7 of 34

Django is a Web Application Framework, written in Python

Allows rapid, secure and agile web development.

Write better web applications in less time & effort.

8 of 34

Django is loaded with security features that are used by default.

Security by default provides great protection to developers with no security experience

Django makes it more difficult to write insecure code.

9 of 34

Django is used by many popular websites/services:

10 of 34

Security Features of Django

Django provides many default protections against web threats, mainly against problems of:

User Management
Authorization
Cookies
SQL Injection
Cross Site Scripting (XSS)
Cross Site Request Forgery (CSRF)
Clickjacking
Files
E-mail Header Injection
Cryptography
Directory Traversal

11 of 34

User Management

Developers make many mistakes in user management.

Passwords are stored/transferred as plaintext.

Users are exposed if databases get leaked.

Weak authentication methods are used by inexperienced developers.

12 of 34

User Management

Django provides a default User model that can be used in any website. It comes equipped with correct session management, permissions, registration and login.

Developers don’t need to re-invent the wheel and re-introduce user management risks.

Django provides strong password hashing methods (bcrypt, PBKDF2, SHA1), with increasing work factors.
Django makes passwords very hard to crack.

13 of 34

User Management

Django provides easy methods for user management such as is_authenticated(), permission_required(), requires_login(), and more, offsetting difficult session and permission code away from the developer.

Django provides secure default password reset and login redirection functionality. Developers don’t need to create password reset forms and introduce risks.

By using Django’s user management module, developers will not make mistakes such as ‘admin=true’ in cookies!

14 of 34

Clickjacking

Clickjacking is an attack where an attackers loads an invisible page over a visible one. The user thinks he is clicking on the visible page, but he’s actually clicking on invisible buttons and links.

Can be used to trick users into buying items, deleting content or adding fake friends online.

Django provides direct protection against Clickjacking attacks using the X-Frame-Options header. Only one line of code!

15 of 34

Clickjacking Example

Image taken from ‘Busting Frame Busting’ research paper (found in references)

16 of 34

Cross Site Scripting (XSS)

XSS is one of the most dangerous and popular attacks, where users instead of servers are targeted.

In an XSS attack, an attacker runs evil scripts on the user’s browser, through a vulnerable website.

It can be used to steal cookies, accounts, install malware, deface websites and many more uses.

17 of 34

Cross Site Scripting (XSS)

XSS is very easy to introduce by ignorant developers, example:

It’s okay if the search query was Car, but what if the attacker entered…

<?php

echo "Results for: " . $_GET["query"];

19 of 34

Cross Site Scripting (XSS)

Evidently XSS is a critical attack, so Django provides great default protections against it.

HTML output is always escaped by Django to ensure that user input cannot execute code.

Django’s templating engine provides autoescaping.

HTML Attributes must always be quoted so that Django’s protections can be activated.

For extra XSS protections, use ESAPI, lxml, html5lib, Bleach or Markdown

20 of 34

SQL Injection (SQLi)

SQL Injection is a dangerous attack in which evil data is sent to the database to be executed as destructive commands.

Developers write SQL queries in a wrong way, allowing attackers to inject SQL commands into the query, to be executed as SQL code. Example:

Looks innocent, but what if the user entered ‘; DROP TABLE USERS;-- ?

string sql = “SELECT * FROM USERS WHERE name=‘” +

Request[‘username’] + “’”;

22 of 34

SQL Injection (SQLi)

SQL injection attacks are used to read and corrupt databases, take complete control over servers as well as modify web pages (and therefore steal user sessions or install malware)

The good news is that Django provides excellent defense against SQL Injection!

Django uses ORM and query sets to make sure all input is escaped & validated.
Developers do not need to write any SQL. Just write Python classes and Django will convert them to SQL securely!

23 of 34

SQL Injection (SQLi)

No matter where input comes from (GET,POST,COOKIES), Django will escape all input that goes to the database.

Even if developers needed to write raw SQL, they can use placeholders like "Select * from users where id = %s ” which will safely validate input.

24 of 34

Django sets cookies to HttpOnly by default, to prevent sessions from getting stolen in most browsers.

Session ID are never used in URLs even if cookies are disabled.

Django will always give a new session ID if a user tried a non-existent one, to protect against session fixation.

Cookies can be digitally signed and time-stamped, to protect against tampering of data.

25 of 34

Files

Django provides excellent protection to files.

No webroot concept in Django. Only the directories and files you allow are requested. Even if attackers upload a file, it is only downloaded if you allow it in URLConf.

Django executes Python code from the outside of the web root, so attackers cannot retrieve any files not explicitly allowed from the web root.

26 of 34

Cross Site Request Forgery (CSRF)

CSRF is an attack where an attacker can force users of a website to perform actions without their permission.

If a user is logged into website A, an attacker can let a user visit website B, which will perform actions on website A on behalf of the user.

This happens because the forms in website A are not protected against CSRF.

Basically CSRF means evil websites can let users of other websites perform actions without user permission.

27 of 34

Cross Site Request Forgery (CSRF)

Example: A form in website A allows a logged in user to delete his account. If there is no CSRF protection, website B can force visitors to delete their account on website A.

Example: Suppose website B has this HTML form in its code. What happens if a user of website A visits B?

</form>

29 of 34

Cross Site Request Forgery (CSRF)

The effects of CSRF is that attackers can make users perform ANY action on the vulnerable website.
Django provides CSRF protections for all POST,PUT,DELETE requests (according to RFC2616).
If website A used Django CSRF protection, the form would be:

</form>

30 of 34

E-mail Header Injection

E-mail Header injection is a less popular attack that targets weak email-sending forms in websites.
By crafting a special string, attackers can use your email form to spend spam through your mail server, resulting in your domains/IPs getting blocked and possible worse effects.

Example email form:

To: mycustomer@example.com

Subject: Customer feedback

31 of 34

E-mail Header Injection

What if the attacker supplies the following data as the email content? They will be able to use your website as a spam base.
“\ncc: spamVictim@example.com\n<spam content>”
It would be:

Django provides default protection by using the built-in email form.

To: mycustomer@example.com

Subject: Customer feedback

cc: spamVictim@example.com

32 of 34

Final Remarks

It must be understood that nothing can protect developers if they refuse to learn about web security and vulnerabilities.

The point of Django’s default security features is to make it very easy to add security, and very difficult to remove security.

However, developers still need to learn the basics of security and risk assessment.

Knowledge is the best defense against web attacks.

33 of 34

References

http://davidbliss.com/sites-built-using-django

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

http://www.djangobook.com/en/2.0/chapter20/

http://seclab.stanford.edu/websec/framebusting/framebust.pdf

34 of 34

Questions?

Do not hesitate to ask any question!

Do not hesitate to let your developers try Django in the workplace! It could be your road to increased productivity and security!

1 of 34

2 of 34

3 of 34

4 of 34

5 of 34

6 of 34

7 of 34

8 of 34

9 of 34

10 of 34

11 of 34

12 of 34

13 of 34

14 of 34

15 of 34

16 of 34

17 of 34

18 of 34

19 of 34

20 of 34

21 of 34

22 of 34

23 of 34

24 of 34

25 of 34

26 of 34

27 of 34

28 of 34

29 of 34

30 of 34

31 of 34

32 of 34

33 of 34

34 of 34