Part 3 – The OWASP Top 10 Web Application Vulnerabilities

OWASP (The Open Web Application Security Project) describe themselves as a “worldwide not-for-profit charitable organization focused on improving the security of software” . They run a number of projects related to web application security, however the project they are best known for is the Top 10 Most Critical Web Application Security Risks. The latest version of this list is from 2017 and is as follows:

1. Injection
2. Broken Authentication
3. Sensitive data exposure
4. XML External Entities (XXE)
5. Broken Access control
6. Security misconfigurations
7. Cross Site Scripting (XSS)
8. Insecure Deserialization
9. Using Components with known vulnerabilities
10. Insufficient logging and monitoring

In this section we will describe each of these vulnerabilities in more detail.

1. Injection

Injection happens when an attacker sends data to a web application with the intention of making it carry out a task that it was not designed to do. One of the most common examples of this type of attack, according to OWASP, is a SQL injection attack. This is where a specially crafted URL is sent to the web application that causes it to return data that it should be providing to the user. An example provided in the OWASP Top 10 is

:

In this example, the following URL could be used to return all the rows in the accounts table:

Applications can be vulnerable to this entry in the OWASP Top 10 when they do not correctly validate, filter or sanitise data that is sent to it as a parameter. The most effective method of detecting this kind of vulnerability is through a code review, followed by a thorough automated testing of all parameters.

The OWASP Top 10 suggests four main methods of preventing or limiting the impact of this kind of attack. They are: 

• Use a safe API, which avoids the use of an interpreter entirely.
• Use positive or “whitelist” server-side input validation.
• Escape special characters using the specific escape syntax for that interpreter – for example, do not allow the use of the double dash in SQL queries.
• Use SQL controls like LIMIT to reduce the impact of any compromise to a limited number of records.

2. Broken Authentication

It is essential for applications to be able to successfully identify and authenticate users to their system. There are many ways in which an application might contain weaknesses in authentication. These include:

• The application permits the use of a credential stuffing account. Lists of the valid credentials for millions of users are freely available on the web. Many web applications do not effectively secure themselves against attacks of this nature.
• Again, scripts are freely available on the web to allow an attacker to attempt to brute force access to an application by trying every known possible combination of characters to guess a password.
• The application allows the use of weak passwords like Password1.
• It uses a weak method of recovering forgotten passwords, like knowledge-based methods. 
• Storing or sending passwords in plaintext.
• Not using two factor authentication, or not using it correctly.
• Incorrect usage of session IDs – ID exposed in the URL or IDs not correctly invalidated after use.

The OWASP Top 10 recommend the following as methods of preventing this kind of web vulnerability:

• Use multi-factor authentication to prevent credential stuffing attacks.
• Do not develop products with default credentials, particularly for admin users.
• Check for weak passwords on a regular basis.
• Implement sensible password management policies, including relating to the length and complexity of passwords, as well as the rotation policy.
• Use the same message for all outcomes related to user registration and password recovery to help prevent attacks from successfully carrying out enumeration.
• Limit or delay failed login attempts to prevent brute force attacks.
• Use server-side session management tools.

3. Sensitive Data Exposure

As the name suggests, this vulnerability relates to the exposure of sensitive data, either at rest or in transit. This could be credit card or financial information, medical data or any other form of sensitive data, the loss of which could be catastrophic. There are various regulations in place that relate to this vulnerability, for example PCI-DSS and GDPR in the EU. An application is vulnerable if it:

• Transfers data in plaintext, for example over HTTP (rather than HTTPS) or over unencrypted SMTP.
• Uses old or weak encryption algorithms.
• If any user agent, for example a web browser, does not effectively check any certificates presented.

These kinds of vulnerabilities can be mitigated by the following techniques:

• Proper classification of data that is both being stored or transmitted.
• Applying the relevant controls to data based on this classification.
• Not storing sensitive data unnecessarily.
• Encrypting all sensitive data at rest.
• Using up to date encryption algorithms with proper key management.
• Encrypt all data in transit, for example using TLS.
• Store passwords using strong hashing functions.
• Obtain independent verification of the effectiveness of configuration and settings.

4. XML External Entities (XXE)

This type of vulnerability allows attackers to exploit vulnerable XML processors by uploading malicious XML documents containing hostile code. Many older XML processors allow external entities to be specified by URI that is then evaluated during processing. Applications and XML-based web services could be vulnerable to this form of exploit under the following conditions:

• The application accepts XML directly or as an upload from untrusted or unknown locations, which is then parsed by an XML processor.
• If any of the XML processors in use by an application has Document Type Definition (DTD) enabled.
• The use of Security Assertion Markup Language (SAML) by an application for identity management in either a federated security or single sign on (SSO) system.
• Applications using older versions of Simple Object Access Protocol (SOAP) prior to version 1.2 are likely to be susceptible to this vulnerability.
• Vulnerability to XXE attacks likely means that the application is also vulnerable to specific Denial of Service attacks.

XXE vulnerabilities can be prevented by the following methods:

• Foremost is developer training to identify and mitigate this type of vulnerability.
• Use fewer complex data formats like JSON.
• Upgrade and patch all XML processors, libraries and SOAP.
• Disabling DTD and external entity processing by XML parsers.
• As with other vulnerabilities in the top 10, implement server-side positive input validation.
• Confirm that any file uploads validate incoming XML.
• Manual code reviews are an essential part of confirming that applications are not vulnerable to a number of major vulnerabilities. This also applies for XXE. 

5. Broken Access Controls

Access controls ensure that users are not able to access information that they should not otherwise have access to. Broken access controls will often lead to unauthorised information disclosure, modification or even the destruction of data. Access control vulnerabilities can be caused by the following issues:

• Modifying the URL to bypass access checks or through the use of an API attack tool.
• Elevation of privilege – acting as a user when not logged in, or acting as a user with admin privileges when logged in as a regular user.
• Metadata manipulation, for example replaying access control tokens to a vulnerable application.
• Cross Origin Resource Sharing (CORS) Misconfiguration.
• The ability to browse to authenticated pages when not authenticated, or pages which should be restricted when logged in.

These kinds of vulnerabilities can be prevented by implementing the following:

• Deny access to everything by default, except for public resources.
• Make sure that directory listing is disabled and that file metadata like .git directories are not web accessible.
• Ensure that access failures are logged and administrators are alerted.
• Configure rate limiting on API and controller access to limit automated attacks.

The following is an example of a Broken Access Control vulnerability detailed in the OWASP Top 10:

The application uses unverified data in a SQL call that is accessing account information:

An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user’s account.

6. Security Misconfiguration

In this entry in the OWASP Top 10, attackers attempt to exploit unpatched flaws or access default accounts. This can include accessing unused pages or unprotected files and directories to gain unauthorized access to the system.

Applications may be vulnerable to this form of vulnerability if any of the following apply:

• Proper hardening of the application has not been carried out, or the appropriate permissions have not been applied to the cloud infrastructure.
• Features that are not required by the application have been left enabled, like open ports or accounts.
• Default accounts have not been removed or had their passwords changed.
• Error handling leaves stack traces available to the public, like core dumps for example.
• When systems are upgraded, the latest security features are not enabled or configured correctly.
• Security settings for application servers, databases or libraries are not configured securely.
• Out of date software is in use, containing known vulnerabilities.

To reduce the risk of this type of vulnerability, secure installation processes should be implemented, which could include some of the following:

• A standardised hardening process that is simple and repeatable to create a secure, locked-down environment.
• A minimal platform, removing all unnecessary features, including documentation, examples etc.
• A regular review of patch management, ensuring that all the latest patches and configurations have been applied as appropriate, including a regular review of cloud permissions.

• Segmentation and containerisation of applications where possible.
• Automated verification of the security configuration at regular intervals.

The OWASP Top 10 provide a number of example attack scenarios for this type of vulnerability, one of which is not removing sample applications that come with an application. These samples could contain known vulnerabilities that can be sought out and exploited.

7. Cross-Site Scripting (XSS)

Cross-Site scripting (XSS) is the second most common vulnerability in the OWASP Top 10 list, with around two thirds of all applications being susceptible. Automated tools can be used to discover the three forms of XSS vulnerability. 

Figure 3.1 – Diagram showing an example of Cross Site Scripting

The three types of XSS are:

• Reflected XSS – This is where an application allows unvalidated or sanitised user input as part of HTML output. If successful, this can allow an attacker to execute arbitrary JavaScript in a user’s browser. Generally, a user will need to click on a link, possibly sent by email, that sends the victim to a vulnerable application, for example a malicious watering hole.
• Stored XSS – This form of XSS is where the application stores unsanitized user input which is viewed at a later time by another user or possibly administrator. One example of this could be a malicious script posted in a forum application. This is considered one of the most critical risks.
• DOM XSS – JavaScript frameworks or single page applications that dynamically include attacker controllable content on a page are vulnerable to this form of attack.

XSS vulnerabilities can be avoided by the following:

• Use frameworks like React JS that automatically prevent XSS.
• Escaping untrusted HTTP request data.
• Enabling a Content Security Policy.

Common forms of attack using XSS include session stealing and attacks against a user, like malware downloads or keylogging. Here is a typical scenario provided in the OWASP Top 10:

Scenario #1: The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

The attacker modifies the ‘CC’ parameter in the browser to:

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.

8. Insecure Deserialization

This form of vulnerability is more difficult to exploit as it will usually require a degree of customisation. Insecure Deserialization is included in the OWASP Top 10 based on an industry survey as opposed to any quantifiable data. It is therefore difficult to provide much detail on this vulnerability.

Applications could be vulnerable to this form of exploit if they deserialize hostile objects provided by an attacker, resulting in two forms of attack:

• Object and data structure related attacks. This occurs if there are classes available to the application that can change behaviour during or after deserialization.
• Data tampering attacks, for example access-control attacks, where existing data structures are used but the content is changed.

Serialization could be used in applications under the following circumstances:

• RPI/RPC
• Wire protocols, web services or message brokers
• Caching
• Databases, cache servers and file systems
• HTTP cookies and HTML form parameters

This form of vulnerability could be mitigated by implementing one or more of the following processes:

• Integrity checks, like digital signatures on serialized objects.
• Enforcing strict type constraints during deserialization.
• Isolate code that deserializes objects to low privilege environments if possible.
• Log deserialization exceptions and failures.

The OWASP Top 10 gives the following as an example of insecure deserialisation:

A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing user state and passing it back and forth with each request. An attacker notices the “R00” Java object signature, and uses the Java Serial Killer tool to gain remote code execution on the application server.

9. Using Components With Known Vulnerabilities

This is a widespread problem due to heavy use of components by development teams, and those teams not knowing or understanding what components they are actually using and whether they are up to date. Scanners can be used to help automate the detection of this type of vulnerability.

Applications are likely to be vulnerable under the following circumstances:

If the developers do not know the versions of all client and server-side components being used by the application, including nested dependencies.

If the software in use is vulnerable, unsupported or out of date, including:

• The Operating System
• Web or Application Server
• Database Management System (DBMS)
• Applications
• APIs and components
• Runtime environments
• Libraries

If regular vulnerability scans are not carried out.

If the underlying platform, framework and dependencies are not upgraded on a timely basis.

If upgraded libraries are not compatibility tested.

If the component configurations are not secured.

This type of vulnerability can be prevented by implementing a sensible patch management process which includes the following:

Removing unused dependencies and features, components, files and documentation that is unnecessary.

Ongoing process to inventory the versions of client and server-side components, using automated tools to monitor for new vulnerabilities.

Obtaining components from official sources only, ideally using signed packages.

Looks for components that appear to have been abandoned by their developers.

As components will usually run with the same privileges as the application, flaws in any component can have a significant impact.

10. Insufficient Logging and Monitoring

Almost every major incident relies on insufficient logging and monitoring, with a lack of timely response allowing hackers to achieve their goals. Again, this entry in the OWASP Top 10 is based on industry survey rather than on any specific data.

An application can be said to be vulnerable under the following circumstances:

• Logins, failed or successful are not logged, along with other high value transactions.
• Warnings and errors do not generate adequate log messages, or no message at all.
• Application logs are not monitored for suspicious activity.
• Logs are only stored locally.
• Alerting thresholds and escalation processes are not configured correctly.
• Penetration testing scans do not trigger alerts.
• The application is not able to detect and alert on attacks in real-time or near real-time.

These vulnerabilities can be prevented by the following:

• Ensuring that all login or access control failures are suitably logged.
• Ensure that logs are generated in a format that can be used by a centralised log management system.
• High value transactions have an audit trail.
• Monitoring and alerting is configured in a way that allows for the timely response to incidents.
• Creation of an Incident Response and Recovery plan.

As highlighted in the OWASP Top 10, the principal risk in this type of vulnerability is the loss of critical data or services caused by a failure to respond in a timely manner.

Figure 3.2 below shows an example of a cPanel hosting control panel where logging is not configured correctly. In this case, logs would only be retained for a few hours. Logs should be archived and ideally not removed each month.

Figure 3.2 – Example of cPanel Control Panel logging configuration

Move on to Part 4 – OWASP Top 10 Vulnerabilities Affecting WordPress Application

Back to Part 2 – Content Management System – A Background