Skip to Content

Technology Blog

Technology Blog

The case for a Django upgrade

Recently updated on

It boils down to this. An upgrade costs money, sometimes a lot of money, but the result has no visible outcome. In fact, in many cases the only outcome is an assurance that you've reduced the probability of attack, intrusion, breach and related unpleasantness. By any measure, that's a tough sales pitch. It's hard to get people to pay for things they can't see.  But, like eating your Brussels sprouts, it is important for good health and is part of the cost of doing business online.

In an effort to provide believable ammunition to those seeking upgrade funds, we thought it might be helpful to offer some specifics.  Although the following is presented through the lens of a website using Python and Django, the principles remain the same for any language or framework.

Support for Django 1.8 ends in April 2018.  Django is on a consistent release schedule where each third version is a long-term release, meaning it is supported longer than the others.  There are plenty of good reasons to upgrade for each release, but the most important upgrade is from one long-term release to another.  In this case, users of Django 1.8 should upgrade to Django 1.11 before April.  Here are a couple reasons why:

Are you on Django 1.8.9 or lower?  
Here's a vulnerability rated as "high" by the National Institute of Standards and Technology:

The utils.http.is_safe_url function in Django before 1.8.10 and 1.9.x before 1.9.3 allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks or possibly conduct cross-site scripting (XSS) attacks via a URL containing basic authentication, as demonstrated by\

A real world exploit of this vulnerability happened in the 2017 high-profile hack of the mega-gaming site, Steam.  

Are you on Django 1.10 or lower?  
This one's a "medium":

A maliciously crafted URL to a Django (1.10 before 1.10.7, 1.9 before 1.9.13, and 1.8 before 1.8.18) site using the django.views.static.serve() view could redirect to any other domain, aka an open redirect vulnerability.

This happened with the popular OAuth and OpenID login platforms.

From Django 1.8 to Django 1.11, there have been 15 individual security vulnerabilities patched.  Each one has a story.  In their wake are hacked websites, compromised customer data, PR nightmares, mea culpas and damage control.

The Open Web Application Security Project (OWASP) is a world-wide not-for-profit organization focused on improving software security.  They are most famous for their Top 10 list (PDF) of the most critical web application security risks.  With the speed of advancing technology, you'd think this list changes frequently.  You'd be wrong.

"In fact, it is disheartening to see that the top 10 vulnerabilities exploited overall continue to be those that are more than a year old (and 48% are five or more years old)." 
- HPE Security Research Cyber Risk Report 2016 (large PDF)

Bottom line, if you're the one controlling the budget you must carve out a line item for upgrades.  If you aren't the one controlling the budget, you need to be on record with the strongest possible recommendation for upgrade.  If and when a vulnerability is exploited on your website, no one will be sympathetic when you counter, "Yes, but I saved the company money by not upgrading." For larger companies, it can send you straight to the unemployment line.  For smaller companies, straight out of business.

Share , ,
If you're getting even a smidge of value from this post, would you please take a sec and share it? It really does help.