- Web Application Security Vulnerabilities - 03/01/2020
- Vulnerabilities Framework Latest - 03/01/2020
- Vulnerabilities in Ruby - 03/01/2020
DJango Framework: –
INTRODUCTION: –
Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. Worked by experienced developers,it deals with tackling the different issues found during web development, so we can center around on building our app without thinking about recreating the whole cycle. [2]
Django is a free and open-source web framework, written in Python, which follows the model-view-template (MVT) architectural pattern.
It is maintained by the Django Software Foundation (DSF), an open source foundation established as a 501(c)(3) non-profit.[3]
Django’s essential objective is to facilitate the making of complex, database-driven sites. Django underlines reusability and “pluggability” of parts, less code, low coupling, quick advancement, and the standard of don’t rehash yourself. Python is utilized all through, notwithstanding for
settings documents and information models. Django additionally gives a discretionary regulatory make, read, refresh and erase interface that is
created powerfully through contemplation and arranged through administrator models. [4]
VULNERABILITIES IN FRAMEWORK: –
The application layer is progressively focused by programmers for entrance, and running full stack Python is not anymore/less helpless
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. [1]
1. Session Modification (CVE-2011-4136) Versions 1.2.7 and 1.3.x before 1.3.1
At the point when session subtle elements are stored in the cache, root namespacing is utilized for both session identifiers and application-information keys. This can enable remote assailants to change a session by activating utilization of a key that is equivalent to that session’s identifier.
2.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 capturing includes an assailant increasing unapproved access to a framework utilizing another client’s session information. For this situation, when utilizing contrib.auth.backends. RemoteUserBackend, remote confirmed clients can capture web sessions by means of vectors identified with the REMOTE_USER header
3. 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.
4. Arbitrary URLs Generation (CVE-2012-4520) Versions 1.3.x before 1.3.4 and 1.4.x before 1.4.2
In these variants, the django.http.HttpRequest.get_host work permits remote assailants to produce and show arbitrary URLs by means of made username and password Host header values.
5.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 assault that uses the client’s internet browser to play out an undesirable activity on another site in which the client is at present marked in. The CSRF assurance system in these versions of Django don’t legitimately deal with web-server setups supporting arbitrary HTTP Host headers, enabling remote assailants to trigger unauthenticated manufactured requests through vectors including a DNS CNAME record and a site page containing JavaScript code.
6. 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 forms of Django, remote aggressors can read or execute documents by means of a/(slice) character in a key in a session treat, identified with session replays.
7.DoS: Via Unspecified Vectors (CVE-2015-5145) Versions 1.8.x before 1.8.3
DoS is short for Denial of Service, and happens when an assailant cuts down a system/site by flooding it with information bundles.
The validators.URLValidator in these renditions of Django enable remote assailants to cause a denial of service (CPU utilization) by means of unspecified vectors.
8.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.
9. 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 enables remote assailants to cause a denial of service (session store utilization) by means of numerous solicitations with one of a kind session keys.
10. 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 don’t legitimately approve HTTP requests that contain a X-Requested-With header, making it insignificant for remote attackers to do cross-site request forgery (CSRF) assaults through produced AJAX requests that leverage a “blend of program modules and sidetracks,” a related issue to CVE-2011-0447.
REMEDIATION:
To fix the above specified common vulnerabilities, we’ll have to refresh the present working adaptation of your Django structure in the entirety of your surroundings. And keeping in mind that Django is in reverse perfect, it is in any case vital that you recognize any segments in your web application that may be affected by fixing/refreshing. [1]
At Valency Networks, we understand your web application and perform framework specific checks mentioned above. Our expertise in this matter enables us to be very accurate in terms of our vulnerability finding
RESOURCES:
1. https://www.upguard.com/articles/top-10-django-security-vulnerabilities-and-how-to-fix-them
2. https://www.djangoproject.com/
3. https://www.djangoproject.com/foundation/
4. https://en.wikipedia.org/wiki/Django_(web_framework)