OWASP Top 10 2017 web application vulnerabilities

The Open Web Application Security Project (OWASP) published the 5th revision of their popular OWASP Top 10 list in November 2017. The list contains the 10 most critical security vulnerabilities that threaten modern web applications. First published in 2004, the OWASP Top 10 has been revised several times to reflect changes in the web security landscape in terms of attack techniques, development methodologies, and cybersecurity priorities. The OWASP Top 10 for 2017 contains significant updates compared to its predecessor from 2013.

This article explains each security issue listed in the OWASP Top 10 2017 and demonstrates how to use the Netsparker web application security scanner to find them. And before we dive in, just a reminder that no matter what some vendors may claim, automatically detecting every single issue from the OWASP Top 10 is simply not possible.

A1: Injection

LDAP Injection, OS Command Injection and SQL Injection are all different types of injection flaws. Injection vulnerabilities generally occur whenever untrusted data, such as unsanitized user inputs, is concatenated with instructions before they are parsed. Consider the developer of a router that allows users to ping remote servers for debugging purposes, for example. The easiest way to do this is to execute the operating system’s built-in ping command with a hostname supplied by the the user, potentially opening the way for an injection attack.

This command is then parsed by the installed shell – bash, for example. However, most shells allow users to execute multiple commands in one line if they are separated by a semicolon. An attacker can abuse this fact by sending localhost; cat /etc/passwd to the application. Instead of executing only one command, as anticipated, the attacker succeeds in adding (injecting) another instruction into the query. So, instead of executing ping localhost, the router will also show the content of the /etc/passwd file, because of the injected cat command.

This was one example of an OS command injection. There are many other kinds of injections, such as SQL injections. For information about a real life example of such an attack, and its dangerous repercussions, take a look at our blog post South African Police Web Application for Whistleblowers Hacked via SQL Injection.

Scanning for Injection Vulnerabilities with Netsparker Web Application Security Scanner

Netsparker is able to detect injection vulnerabilities in web applications with ease. By default Netsparker scans a target for a wide range of web application vulnerabilities, but you can easily configure it to scan exclusively for these type of vulnerabilities. All you have to do is add a new Scan Policy and enable the following server side injection vulnerabilities:

• Code Evaluation
• Code Evaluation (Out of Band)
• Command Injection
• Command Injection (Blind)
• Expression Language Injection
• SQL Injection
• SQL Injection (Blind)
• SQL Injection (Boolean)
• SQL Injection (Out of Band)

Once you have selected the relevant vulnerabilities select your newly created Scan Policy from the Start a New Website or Web Service Scan dialog, as illustrated.

A2: Broken Authentication

Authentication in web applications is used to verify user identities and authorize access to sensitive information. Security risks related to authentication and session management include password theft, session hijacking using compromised tokens, and impersonating legitimate users. Common vulnerabilities related to authentication are typically exploited via password reset functionality by tampering with tokens such as cookies and session IDs.

Attackers are able to bypass authentication if implemented incorrectly. This enables attackers to log in as any user they wish. This function that aims to check whether the right password for a given user was provided:

1    function checkLogin() {

2          if (post['user']) {

3                      user = post['user'];

4          }

5          if(post['password']) {

6                      data = getDataFor(user)

7                      if(data['password'] != post['password'])

8                      return false

9          }

10        return user

11 }

The problem with this code is that it is broken at a fundamental level. There is code that compares the user-supplied password with the one stored in the database and returns false if the password doesn’t match (see lines 6-8). The problem is that this check only runs if the user sends a password (see line 5). If a user only sends a username without a password, an attacker can log in as any user that is registered on the website.

However, this is certainly not the only way in which authentication mechanisms can be broken. There may be insecure password storage in the backend (not using a suitable hashing algorithm, for example), broken two-factor authentication, or information leaks that disclose whether or not a user exists on the system.

A3: Sensitive Data Exposure

Sensitive information stored in databases (or anywhere else) should be well protected. Credit card details, social security numbers and other sensitive customer details should be encrypted when stored in a database, even if they are not directly accessible through a web application. The same applies for sensitive data that is transmitted to and from the web application, such as credentials or payment details. Such information should be also be transmitted over a secure and encrypted layer.

Formerly, sensitive data exposure led to a vast amount of data suddenly becoming available to anyone who was willing to search for it. Misconfigured MongoDB instances were blamed for such breaches; now, publicly-accessible S3 buckets are the main culprit. They are named after ‘Simple Storage Service’, a facility that is part of the Amazon Web Services (AWS). AWS users can store data in these buckets and decide who has access to them. However, they are often configured incorrectly, and can then be viewed by unauthenticated users, or by anyone with an AWS account.

Identifying Sensitive Data Exposure with Netsparker Web Application Security Scanner

You cannot rely on automated means to find all types of sensitive data, simply because what data is considered as sensitive depends on the application. While a home address on a contact page may have been placed there on purpose, it probably shouldn’t be visible in an online forum where users expect anonymity.

What Netsparker can do is inform you if it finds a suspicious-looking string on a website, such as an SSN or credit card number. To add these checks into your custom Scan Policy, it’s enough to simply select the Signatures check group as shown in the below screenshot. It contains checks for all kinds of information disclosures, including detected software version numbers.

These checks are conducted without making additional HTTP requests. You can deactivate the checks you don’t need from the Security Checks lists on the right. Since you aren’t making any additional requests, you can use it in conjunction with any other policy, without impacting performance.

A4: XML External Entities (XXE)

XML External Entity attacks are a new entry in the OWASP Top 10 2017. They are often abused by attackers to gain access to local files, bypass whitelist restrictions and interact with services behind firewalls. Even though such vulnerabilities are popular (they made it to the OWASP Top 10 list) many parsers still allow external entities by default.

XML Entities are like variables: they will expand to a defined value once they are processed by the XML parser. Even many who are not familiar with XML might have seen such an entity in a different place, such as HTML code. For example Instead of copy and pasting characters like the copyright symbol (©) you can conveniently write © and the browser will display it correctly. These are predefined and can’t be changed using HTML code.

However, XML gives you a way to define your own entities in order to make coding and configuration easier. An example (in an XML file) where this is necessary is in a customizable configuration file in a web application. For example you need to use a website’s name in multiple locations, such as the page title or footer, or for email templates. Instead of setting the name in each and every single XML tag, it’s easier to define the XML Entity called &sitename; in which to hold this information and use it where necessary. So whenever you want to change the website name, you need only change it in the entity definition once, not in every single XML tag.

XML has other advantages too. For instance, XML allows you to define external entities. These are entities that may contain the content from a remote website or API endpoint. When called the XML parser will automatically fetch the external entity and include it in the XML file. That way, you can easily change the meaning of multiple documents without having to edit them manually.

However, there is one problem. If it is possible to pass XML documents to an XML processor that supports external entities, attackers can retrieve content from a website behind a firewall, issue service requests, or discover the content of files stored on the server. Because entities can be referenced within entity definitions, attackers can craft an XML document that contains only 10 entities but will eventually expand to, say, a billion entities once it is parsed. When used for denial of service attacks, this is known as the “Billion Laughs Attack”.

Detecting Enabled XML External Entities with Netsparker Web Application Security Scanner

XXE Vulnerabilities are among the vulnerabilities that Netsparker can confirm with the highest degree of accuracy. This is because they often result in outbound requests that can be detected by our Netsparker Hawk vulnerability testing infrastructure. If you are building your Scan Policy and want to include XXE, there are a few simple steps to follow. Simply select the two XML External Entity Security Check Groups and proceed as before.

A5: Broken Access Control

Broken Access Control is a new category of vulnerability. It was created by merging Insecure Direct Object References (IDOR) with Missing Function Level Access Control from previous OWASP Top 10 lists. Broken Access Control refers to restrictions that are not properly enforced. It occurs for example when authenticated users without administrative authority can create new administrator accounts.

A common example of such a vulnerability is an admin panel that relies heavily on JavaScript to execute certain actions, such as the creation of an admin account. For this to work, there has to be an API endpoint on the same domain, that can be accessed using JavaScript. The script code on the admin panel is issuing requests to this API endpoint and adds a new user without having to reload the page. There may be different user roles, and not all of them may be allowed to create admin users.

This restriction should be enforced on the server side. But it’s a common mistake to remove the JavaScript code that issues the API request. Even though a user can’t see it, the endpoint is still available and can be used without any authentication. It is possible for an attacker to guess both the URL and parameters of a specific endpoint or, in case of publicly-available software, to install it on a local machine and find it by looking at a fully functional admin panel.

Detecting Broken Access Control Issues with Netsparker Web Application Security Scanner

Sometimes it is difficult to determine objectively what constitutes as broken access. Consider the following example; should the Helpdesk Operator of a health insurance company be able to see personal health records?

Some may not have a problem with this. Others might feel uncomfortable with the thought that a Helpdesk Operator might know intimate details about the health issues the discussed in confidence with their doctor. So, if it is difficult for humans to determine, with objectivity, whether or not a certain user group should have access to specific information or functionality, it is much more difficult, to the point of impossibility, for software to do so.

Netsparker can help you test your application manually, by using the HTTP Request Builder tool. To continue with the example of the health records application, the POST parameters to retrieve the data may look like this:

patient_id=291492&action=request_data&include_health_record=true

If you want to test whether a user without the administrator role can access these records too, copy that user’s session cookie into the Netsparker Request Builder. You can do this by using a Header parameter as illustrated below. All you need to do is specify the required POST parameters too.

You can either directly send the request or use the Raw view to check if everything looks correct (click the Raw tab).

If the endpoint returns a patient record, this means that there is a broken access control mechanism in place.

A6: Security Misconfiguration

Web application security is not just about secure web application coding. To ensure the security of a web application, it is also important to:

• secure the configuration of the web server,
• secure the operating system of the web server,
• ensure that the server is always updated with the latest security patches.

The same applies for the web frameworks used on the web server, such as PHP and NET. Such a misconfiguration can result in a vast number of vulnerabilities. One of the more harmless types of vulnerability is the disclosure of the software version that’s in use. This is usually not a problem if the application is up to date.

Both the XXE and Sensitive Data Exposure issues are also the result of a security misconfiguration. By interacting with certain services, that are running behind a firewall on the machine, it is possible to gain remote code execution through an XXE vulnerability. Sensitive data exposure might include passwords that eventually leads to the same result – a server under the control of attackers.

It’s not easy to pinpoint a single severity for general security misconfigurations. They can range from a harmless information disclosure to a critical remote code execution.

Identifying Security Misconfiguration with Netsparker Web Application Security Scanner

No web application scanner can analyse the internal configuration files of a server or a piece of software and tell you which of the configuration directives are flawed. But this is not necessary in order to determine whether an instance might be misconfigured or not. A good example is allowing directory listings in a web server configuration. Netsparker can inform you of such directory listings once it detects them.

The policy to detect this specific misconfiguration is the same as the one mentioned in A3, Sensitive Data Exposure. For example Netsparker will alert you if directory listing is enabled, if the web server software is out of date or if other features that might result in security issues are enabled.

A7: Cross-site Scripting (XSS)

A cross-site scripting (XSS) vulnerability allows hackers to inject malicious client-side script into a website or web application that is later executed by the victim’s browser. Typically, cross-site scripting attacks are used to bypass access controls and to impersonate legitimate users, such as the web application administrator. Some years ago, a cross-site scripting vulnerability was used along with other vulnerabilities to gain root access on the Apache Foundation servers.

Detecting Cross-site Scripting Vulnerabilities with Netsparker Web Application Security Scanner

Every web application security scanner can detect XSS vulnerabilities. However many report false positives as well as false negatives, as they are neither context-aware nor can they reliably confirm their results. Another problem is that most scanners are not able to detect one of the three basic types of Cross-site Scripting, DOM based Cross-site Scripting (DOM XSS).

Netsparker can reliably detect reflected, stored, DOM, and even blind XSS vulnerabilities with ease and such checks are included in the default scan policies. To create a scan policy that exclusively checks for XSS issues just select the three required Security Check Groups as shown in the below screenshot. Bear in mind that due to the nature of DOM XSS checks scans might take longer when they are activated.

A8: Insecure Deserialization

Insecure Deserialization is a problem in many programming languages. In recent years, it was the cause of lots of critical vulnerabilities in widespread web applications and frameworks. Its impact ranges from SQL injections to Remote Code Execution. Java and PHP applications were targeted particularly in the past by malicious attackers. This is another new entry to the latest OWASP Top Ten list.

Like security misconfiguration, the impact of Insecure Deserialization can range from harmless information disclosure to critical remote code execution. This is because attackers need to reuse existing code patterns in the application, known as ‘gadgets’. These are classes with a certain method that will be executed once data is deserialized. An example in Java is __wakeup in PHP or readObject.

There may be such methods in the code that don’t necessarily lead to dangerous behaviours. However, in PHP, user-supplied input should never be used in the function that is responsible for the deserialization of PHP objects. It is called unserialize, and apart from deserialization issues, it has also suffered from buffer overflows in the past.

A9: Using Components with Known Vulnerabilities

It is quite surprising that this class of vulnerabilities is in ninth place, since most of today’s successful attacks, such as the infamous Equifax hack and data breach, happen because the attacker exploited a known vulnerability in an outdated software that was still being used. Administrators fail to regularly update all of the software used on their web servers and by web applications with the latest, most secure and most stable versions.

Popular open source products are particularly prone to such attacks, as they are in widespread use and the source code is freely available to both users and attackers. For example, there is a known content injection vulnerability in old versions of WordPress that are still in use on many servers. Shortly after the announcement of the vulnerability, hackers wrote automatic tools to exploit it, and were able to deface a huge amount of websites in a relatively short space of time. It doesn’t always have to take months or years for hackers to target web applications that use components with known vulnerabilities. Sometimes, a few hours is enough!

Detecting Components with Known Vulnerabilities with Netsparker Web Application Security Scanner

Netsparker can automatically fingerprint web applications and alert you of all known vulnerabilities in that specific software component and version. Netsparker also checks the JavaScript and other frameworks you are using to ensure they are not vulnerable.

Such checks are included in the default scan policy. To add them to your custom Scan Policy, just select Web App Fingerprint and JavaScript Libraries from the Security Check Groups list, as illustrated.

Netsparker also heuristically checks for vulnerabilities in your web application, so it will also alert you of any software flaw it comes across. For example, if there is a known XSS vulnerability in the e-commerce web application that you use, it can find it without having to know the software or version in use. In fact in the last few years Netsparker has identified numerous zero day vulnerabilities in web applications, including vulnerabilities in WordPress and Joomla!

A10: Insufficient Logging and Monitoring

Insufficient Logging and Monitoring refers to the inability to log and detect hacking attempts and breaches. Statistics from 2016 show that, on average, it took an organization 191 days to detect a data breach! Activity logging and monitoring is crucial to ensure timely and effective incident response and prevent breaches before they happen.

Imagine a website that allows an administrator to view the private messages of its members. From a privacy point of view, this should only happen under exceptional circumstances. However, nothing would prevent a rogue admin or a hacker that gained admin credentials to read every private message of any user. If there was no proper logging or monitoring in place, an attacker could snoop on users for an indefinite period of time. No attackers or administrators could be detected, since there is no evidence that anyone looked at the messages. No-one can be identified if no IP was logged.

Conclusion

In the OWASP Top Ten 2017, many client-side vulnerabilities, such as XSS and Cross-site Request Forgery (CSRF), were either moved down the list or removed, and some new entries that greatly affect the security of the web server without the need for any user interaction were added.

It should be noted that these changes don’t mean that the impact these vulnerabilities have is less severe than before. CSRF can still lead to the compromise of a web server, and XSS is still the method of choice for attackers to attack specific users.

The OWASP Top 10 list is more of an awareness list rather than a complete list of web application vulnerabilities, as also highlighted on the OWASP website:

The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications.

Therefore, scanning your web applications, web services and APIs with a web application security solution such as Netsparker is vital, if you want to detect vulnerabilities from the OWASP Top 10 2017 and more.