8

The Story:

In one of our projects, we are using Django web framework. But, we are currently stuck at 1.6.11 (mainly because in 1.7 Python 2.6 support was dropped - we are working on it, but it's going very slow) which is not maintained anymore. No security fixes have been applied to 1.6 for quite a long time.

I'd like to facilitate the upgrade process by proving the management that we have a problem from a security perspective.

The Question:

Could you recommend me a strategy/way to demonstrate/prove that using Django 1.6 is not safe anymore?

alecxe
  • 1,515
  • 5
  • 19
  • 34
  • 2
    Have you checked vulnerability databases? [CVE Details](https://www.cvedetails.com) or [the CVE Databse](https://cve.mitre.org/cve/) would be a good start. CVE Details will give a "Threat Level" number which may be more palatable to management than a proof of concept or whitepaper. [Rapid7](https://www.rapid7.com/db/search?utf8=%E2%9C%93&q=django&t=a) or [Exploit-DB](https://www.exploit-db.com/) are other places to poke around as well. – INV3NT3D Dec 21 '16 at 19:51
  • 1
    @INV3NT3D okay, this would be a good start, will go through the vulnerability databases. Thanks! – alecxe Dec 21 '16 at 19:54

3 Answers3

7

I use Django a good deal and I did need to migrate 1.6 to 1.7 (although it was some 2-3 years ago). During that time the most important difference in terms of security was django.contrib.messages, which was not aware of HTTPS only cookies in Django 1.6. In other words, if you had something like:

MESSAGE_STORAGE = 'django.contrib.messages.storage.cookie.CookieStorage'

Instead of session storage, and the website was configured to send cookies only for HTTPS connections, then those cookies would be sent over plain HTTP anyway.

Extra note:

The Django release process states that once a version 2 numbers higher is released the security patches for a version cease, unless the given version is a LTS (long time support version). Therefore Django 1.7 is not receiving any security updates anymore since Django 1.9 (and even Django 1.10) has been released.

You should aim to upgrade to Django 1.8 since it is an LTS version of Django. Which will receive security updates 'till April 2018.

grochmal
  • 5,677
  • 2
  • 19
  • 30
  • Wow, this is a great example, I'll look into this vulnerability closer and see if it affects us! Yeah, we should definitely jump to the LTS. It's being a nightmare, we even have a custom csrf middleware manually backported from 1.7, custom backported from 1.7 mail backend that supports "use ssl", we've done terrible things :) – alecxe Dec 21 '16 at 20:13
2

Not every framework upgrade is because of security, but if a version is no longer supported, this also impies there will be no bug/hot-fixes. That should be an important reason to upgrade regardless of the 'better' features in newer releases.

Update

As a counter argument, one could say the increase in functionality enlarges the attack surface, or introduce new bugs.

Yorick de Wid
  • 3,346
  • 14
  • 22
  • Thank you for the input! I understand that. Moreover, there were multiple new things implemented in Django since 1.6 functionality-wise and we can benefit from them, but I'm trying to focus on the practical way of proving the security issues. Ideally, exploit a major problem and show it to the management. – alecxe Dec 21 '16 at 20:07
  • @alecxe See update – Yorick de Wid Dec 21 '16 at 20:18
2

CVE-2016-9013 and CVE-2015-5145 make the Django environment you're running susceptible to a denial of service attack and to information compromise; so poses a formidable information security risk.

With Django 1.6.11 not receiving any security updates anymore there is no way to mitigate these risks (and other risks not mentioned here).

user34445
  • 503
  • 2
  • 12