Popular high-level Python framework Django is widely lauded for its ease-of-use and pragmatic design, but like all software it is susceptible to its own share of critical vulnerabilities. Built completely with Python, the MVC framework has a sizable community and can be extended with app plugins for additional functionality. Ubiquity has its price, however—in this case, Django's open source popularity means that default attack vectors are also widely known.
The application layer is increasingly targeted by hackers for penetration, and running full stack Python is no more/less vulnerable than any of the other application stacks. In fact, BitBucket , dpaste, and Mozilla Support are all employing Python/Django for their mission-critical web offerings, so have no fear—effective vulnerability management and visibility into existing Django security gaps can go a long way towards hardening your Django-based web app against attacks.
Check out our article Full Stack Blues to learn about vulnerabilities in other application stacks.
Django’s Top 10 Vulnerabilities
10. Session Modification (CVE-2011-4136)
Versions 1.2.7 and 1.3.x before 1.3.1
When session details are stored in the cache, root namespacing is used for both session identifiers and application-data keys. This can allow remote attackers to modify a session by triggering use of a key that is equal to that session's identifier.
9. Session Hijacking (CVE-2014-0482)
Versions 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3.
Session hijacking involves an attacker gaining unauthorized access to a system using another user’s session data. In this case, when using contrib.auth.backends.RemoteUserBackend, remote authenticated users can hijack web sessions via vectors related to the REMOTE_USER header.
8. Cache Poisoning (CVE-2014-1418)
Versions 1.4 before 1.4.13, 1.5 before 1.5.8, 1.6 before 1.6.5, and 1.7 before 1.7b4
Cache poisoning occurs when incorrect data is inserted into a DNS resolver ‘s cache, causing the nameserver to provide an incorrect IP address or destination. These versions of Django do not not properly include the:
- Vary: Cookie
- Cache-Control header in response
This can allow remote attackers to obtain sensitive information or poison the cache via a request from certain browsers.
7. Arbitrary URLs Generation (CVE-2012-4520)
Versions 1.3.x before 1.3.4 and 1.4.x before 1.4.2
In these versions, the django.http.HttpRequest.get_host function allows remote attackers to generate and display arbitrary URLs via crafted username and password Host header values.
6. CSRF: Unauthenticated Forged Requests (CVE-2011-4140)'
Versions through 1.2.7 and 1.3.x through 1.3.1
CSRF is short for Cross Site Request Forgery, an attack that utilizes the user’s web browser to perform an unwanted action on another website in which the user is currently signed in. The CSRF protection mechanism in these versions of Django do not properly handle web-server configurations supporting arbitrary HTTP Host headers, allowing remote attackers to trigger unauthenticated forged requests via vectors involving a DNS CNAME record and a web page containing JavaScript code.
5. CSRF Via Forged AJAX Requests (CVE-2011-0696)
Versions 1.1.x before 1.1.4 and 1.2.x before 1.2.5
These versions of Django do not properly validate HTTP requests that contain an X-Requested-With header, making it trivial for remote attackers to carry out cross-site request forgery (CSRF) attacks via forged AJAX requests that leverage a "combination of browser plugins and redirects," a related issue to CVE-2011-0447.
4. Directory Traversal (CVE-2011-0698)
Versions 1.1.x before 1.1.4 and 1.2.x before 1.2.5 on Windows
In these versions of Django, remote attackers are able to read or execute files via a / (slash) character in a key in a session cookie, related to session replays.
3. DoS: Via Unspecified Vectors (CVE-2015-5145)
Versions 1.8.x before 1.8.3
DoS is short for Denial of Service, and occurs when an attacker brings down a network/website by flooding it with data packets. The validators.URLValidator in these versions of Django allow remote attackers to cause a denial of service (CPU consumption) via unspecified vectors.
2. DoS : Via Multiple Requests With Unique Session Keys (CVE-2015-5143)
Versions before 1.4.21, 1.5.x through 1.6.x, 1.7.x before 1.7.9, and 1.8.x before 1.8.3
The session backends in Django allows remote attackers to cause a denial of service (session store consumption) via multiple requests with unique session keys.
1. Type Conversion Vulnerability (CVE-2014-0474)
Versions before 1.4.11, 1.5.x before 1.5.6, 1.6.x before 1.6.3, and 1.7.x before 1.7 beta
In these versions of Django, the following field classes do not properly perform type conversion :
- FilePathField
- GenericIPAddressField
- IPAddressField
This gives remote attackers access to unspecified impact and vectors related to MySQL.
Remediation
To fix the above vulnerabilities, you'll need to update the current working version of your Django framework in all your environments. And while Django is backwards compatible, it is nonetheless crucial that you identify any components in your web app that might be impacted by patching/updating.
UpGuard provides a way for you to do this easily and automatically with a few mouse clicks. Our powerful policy engine can validate secure configurations for all environments, infrastructures, and application stacks. In this case, a simple Django security policy can be run to check for any of the above vulnerabilities—as well as new vulnerabilities not yet added to policy. Our OVAL-backed vulnerability detection and monitoring suite ensures that all your Django components are free for vulnerabilities and security gaps.
