Understanding the OWASP Top 10 Vulnerabilities (2017)
The Open Web Application Security Project, more commonly known as OWASP, is a community of security professionals, researchers, and enthusiasts who develop tools for security testing, documentation for vulnerabilities for various platforms and articles on the latest developments in cybersecurity.
The OWASP Top 10 refers to the most commonly found vulnerabilities found in web applications. Below are the top 10 vulnerabilities found in web applications as documented and ranked by OWASP for the year 2017.
1. Injection
Injection refers to the attacks which exploit the presence of improper input handling that can lead to the interpretation of the input as part of the code/query it’s being used in making the application perform actions it wasn’t meant to. Injections cover all the different varieties such as SQL Injections, NoSQL Injections, Code Injections, etc.
A simple example would be to imagine a login form with the fields username and password. Let’s assume the SQL query, written in a PHP backend, looks something like -
$username = $_POST['username'];
$password = $_POST['password'];
$query = "SELECT username, password FROM users WHERE username = '" + $username + "' AND password = '" + $password + "'";
Now we can enter abc' or 1=1 -- // as the username and this will change the query structure to retrieve all usernames and passwords irrespective of whether the username matches any other entry or not. The query would end up looking something like -
SELECT username, password FROM users WHERE username = 'abc' or 1=1 -- // 'AND password = '
As it should be evident, the OR condition always returns true since the condition 1=1 is always true and the rest of the query gets commented out.
This category holds its rank as the most common vulnerability since the last release in 2013.
2. Broken Authentication
The attacks based on Broken Authentication allow an attacker to impersonate a legit user to gain access and/or use a service that the web application offers only to privileged users. This vulnerability occurs due to improperly built authentication mechanisms.
An example of broken authentication could be if one user by modifying some parameter(s) can gain access to services/information he shouldn’t be able to. Imagine the system assigns a session ID to every user who is logged in and the URL looks like -
https://www.example.com/?id=1
If a user, by changing the id parameter to a different value, say 2, could get the private page of a different user, then the site has broken authentication.
3. Sensitive Data Exposure
Sensitive Data Exposure occurs when critical information, such as user credentials, are susceptible to be stolen due to either weak encryption mechanisms or complete absence of encryption. Such a vulnerability can invite attacks at various avenues.
For example, if a site does not use SSL encryption, all the traffic for this site can easily be sniffed and read in plaintext and hence, any credentials passed over the network to this site can be compromised.
4. XML External Entities (XXE)
Attacks based on XML External Entities make use of the widely available but rarely used feature present in XML parsers. XML documents can have markup declarations that define the document type enabling the XML parser to verify the document’s correctness before processing it. This markup can be defined with DTDs or Data Type Definition.
Let’s take an application where we can upload XML documents and see the formatted content. Here’s a simple POST request with an XML document with a DTD and the response -
// Request
POST http://randomsite.com/xml HTTP/1.1
<!DOCTYPE user [
<!ELEMENT user ANY>
<!ENTITY user "Ayush">
]>
<user>
Hello &user;
</user>
// Response
HTTP/1.0 200 OK
Hello Ayush
These external entities can be used to perform DoS attacks, access remote and local content, even behind firewalls. Below is an example of a crafted XML document which displays data from /etc/lsb-release file in Unix systems -
// Request
POST http://example.com/xml HTTP/1.1
<!DOCTYPE user [
<!ELEMENT user ANY>
<!ENTITY xxe SYSTEM
"file:///etc/lsb-release">
]>
<user>
&xxe;
</user>
// Response
HTTP/1.0 200 OK
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"
We just read from a system file that we did not have access to. We can, similarly, read from files on the network of the target machine which are behind firewalls.
5. Broken Access Control
Broken Access Control happens due to the absence or insufficient authentication and authorization checks on users accessing privileged services. This can lead to a leak of resources which should either be inaccessible or available to users selectively.
Imagine a scenario where the web application provides a certain service which is supposed to only be available to admins, say edit-database, which is available at <host>/hidden/edits. Now, the backend only checks if a user is logged in and assumes that if he is, that means he is a legit user. So, anyone can navigate to the said resource irrespective of whether they are an admin or not and make changes to the database.
6. Security Misconfiguration
Security Misconfiguration refers to improper configuration of services being set up for the application. This ranges from using default credentials for databases, not removing default credentials, not removing additional bundled services that comes along with packages, using debug mode in production, incorrect directory permissions and so on.
This misconfiguration can occur at any link of the whole application - the server, the database, frameworks, etc.
Django, the widely used python backend framework, lists out all the routes when debug is set to true in its configuration file. This can expose the routes which the attacker might not have had access to and now he can add them to his attack surface.
7. Cross Site Scripting (XSS)
Cross Site Scripting attacks make use of unvalidated content or input being sent to the browser to be rendered. This allows for an attacker to craft a payload which can modify the DOM of the HTML page itself. XSS can further be used to perform actions on the browser without the knowledge of the user being targetted.
There are three types of XSS:
Reflected XSS: The payload script runs on the client side without his knowledge and possibly perform actions on his behalf on the server.
Stored XSS: The payload gets stored on a database and requests that query that payload run the script on their browsers. This kind of XSS is more critical as it can allow an attacker to target an extremely wide user base at once.
DOM-based XSS: The payload exists and executes its purpose on just the browser without ever involving the server.
Let’s take a look at reflected XSS as an example. Imagine that the following URL populates the browser with some content as follows -
https://randomsite.com/?param=hello+world
This renders the HTML page on the browser as so -
<p>hello world</p>
We can modify the value of param to a malicious script -
https://randomsite.com/?param=<script>alert(0);</script>
The resulting HTML will be as follows which will trigger an alert pop-up on the browser -
<p><script>alert(0);</script></p>
The alert() function can be replaced with any javascript that we want to run on the target’s browser.
8. Insecure Deserialization
Serialization refers to the conversion of complex objects, that programming languages make use of, to a format which can be used to store the object or transfer over a network. There are plenty of libraries in languages that provide this utility - pickle for python, serialize() in PHP for example. Conversely, deserialization refers to the retrieval of the data object from serial data.
The attacks which target insecure deserialization of the data are critical as they can allow an attacker to perform DoS attacks, code execution, and bypass authentication.
The below example illustrates the severity of finding an insecure deserialization vulnerability.
import pickle
import os
class BadUserClass():
def __init__(self, username):
self.username = username
def __reduce__(self):
return (self.__class__, (os.system("whoami"),))
bad_user_obj = BadUserClass("ayush")
serialized_obj = pickle.dumps(bad_user_obj)
# Insecure deserialization
user = pickle.loads(serialized_obj)
print("Hello!, {}".format(user.username))
Running the above code provides us with the following output, displaying desktop-fsv539h\ayush -
desktop-fsv539h\ayush
Hello!, 0
It is quite evident that, here, we have the capability of even spawning a reverse shell from the victim and then the whole machine is compromised.
One noteworthy thing about deserialization vulnerabilities is that it’s extremely difficult to identify their existence. Generally, such vulnerabilities are found in white-box testing or when the attacker has some access to the source code of the application.
9. Using Components with Known Vulnerabilities
As technology progresses and a lot of things going open-source, it’s not a big surprise when people find security bugs in existing libraries and frameworks. However, it becomes a vulnerability when the application using such a module as part of its codebase and the module either is not the latest version or does not have the security patches installed to mitigate the known vulnerabilities in that library.
Equifax was a victim of a data breach that arose due to the usage of a version Apache Struts which had a known vulnerability since March 2017.
10. Insufficient Logging and Monitoring
Insufficient Logging and Monitoring refers to the attacks that rely on lack of or inadequate monitoring and/or untimely response to attacks.
An example of the same would be when an application fails to log actions performed by a legit user. Thus, if an insider queries the database, makes modifications, etc. there is no way of tracking him down. Accountability suffers due to insufficient logging and monitoring.