OWASP Top 10: Real-World Examples (Part 2)

In the second article of this two-part series, we’ll give a simple overview of the final fivevulnerabilities listed in the 2017 OWASP Top 10, how to mitigate them, as well as featuring real-world examples from disclosed bug reports to show the exploits in action. Let’s go!

(If you haven’t checked out the first article, you can find it here).

6. Security Misconfiguration

What is it?

Covering a broad range of potential weaknesses, this category of vulnerabilities is actually the most prevalent in web apps today (OWASP Top 10 isn’t ranked on prevalence but rather seriousness, hence why it occupies the number 6 spot here). This can include insecure default configurations, incomplete configurations, misconfigured HTTP headers or exposed error messages which guide attackers in their search for vulnerabilities.

When Does it Happen?

A number of different features can constitute misconfigurations, including:

• Failure to sufficiently harden the application (a lack of firewall, or a misconfigured one).
• Unnecessary exposure, whether it be in the form of web pages, unused accounts or unrequired services.
• Default usernames/passwords kept for administrative tools/hardware — a little Google-fu for product-specific documentation will usually detail them!
• Error messages are outputted on the web server. This can be of use to an attacker if they are overly verbose (e.g. stack traces), potentially revealing file paths, configuration details and specific version details.
• The server does not send security headers (things like Strict-Transport-Security , Content-Security-Policy, X-Content-Type-Options, Referrer-Policyetc), or fails to appropriately set their values.

How to Mitigate Security Misconfigurations

• Take a minimalist approach to your web app — if a feature, framework or function is not required, remove it.
• Ensure that all available updates and patches are applied as soon as possible. Conduct routine checks to ensure this requirement is met.
• Review cloud storage permissions.
• Ensure your HTTP headers are secure — consult OWASP’s guide here for reference or scan your website’s headers by using the free scanner available at https://securityheaders.com.
• Introduce an automated process to routinely check misconfigurations (using Selenium or an equivalent framework).

Real-World Examples

1. Misconfigured HTTP headers in U.S. Department of Defense web page (https://www.sfl-tap.army.mil/). While theX-XSS-Protection header was included, it was configured with the value DENY which is to be used for the X-Frame Option. The researcher correctly recommended that this should be changed to 1; mode=block. The original report can be viewed here.
2. Another HTTP headers example — this time in ReddAPI. An HTTPS page was missing the Strict-Transport-Policy header which is required to ensure that a browser always uses secure protocol when accessing said page. Full information about the report can be reviewed here.

7. Cross-Site Scripting (XSS)

What is it?

One of the better-known vulnerabilities due to its high ranking in OWASP’s Top 10 in years gone by (#3 in 2013 and #2 in 2010), XXS may have dropped down to #7 in 2017 as a result of better knowledge and protection against it. Put simply, Cross-Site Scripting allows an attacker to execute JavaScript in a victim’s browser. This can be used to hijack user sessions (by getting cookies, session IDs and so on), alter the contents of a web page or redirect a user to a malicious site. There are two broad classifications of XSS:

• Stored XSS: this is when an injected script is stored on the server in a fixed location. The classic example is a forum post, where every user which requests the post from the server will subsequently be affected by the stored XSS payload. Also referred to as Persistent or Type-I XSS. For this reason, it is usually classified as the most severe since it will typically impact the highest number of users.
• Reflected XSS: this is when an injected script within a request is reflected back in the server’s response. A common example is a search feature which responds by printing (or reflecting) the user’s search input. Given this format, a reflected XSS attack must involve targeting a victim through another method such as social engineering in order to get them to send the request which elicits a reflected response. Also referred to as Non-Persistent or Type-II XSS.

When Does it Happen?

We’ll break this down by the different XSS types, since they can have different causes:

• Stored & Reflected XSS: the web app or API stores user input which is unsanitised, unescaped, unvalidated or fails to be encoded.
• DOM-based XSS: JavaScript frameworks, single-page applications and APIs which dynamically include user-inputted data are vulnerable to this type of attack.

How to Mitigate Cross-Site Scripting Attacks

OWASP have a couple of excellent XSS prevention cheat sheets: one for reflected/stored attacks, and another for DOM-based attacks. The main steps to enforce are:

• Employ a combination of validating, filtering, encoding and escaping methods to prevent untrusted user input from executing on the web app. The first OWASP cheat sheet listed above goes into extended detail about methods you can use to prevent malicious input executing as intended.
• Move to frameworks which automatically escape XSS by design (i.e. recent Ruby on Rails versions; React).
• Enforce secure headers (such as a well-considered Content-Security-Policy).

Real-World Examples

The list could be pretty extensive for this one, so I’ve shortlisted a prolific example for each type:

1. Stored XSS: A stored XSS vulnerability was discovered in Steam’s React-built chat client. The informative report and steps taken to exploiting it can be viewed on HackerOne here.
2. Reflected XSS: as summarised by Uber’s security team,

Due to a lack of input validation from the search field on lert.uber.com, it was possible to obtain a Reflected XSS from the URL path, e.g. https://lert.uber.com/s/search/All/Home">PAYLOAD.

3. DOM-based XXS: a vulnerability in the DuckDuckGo search engine was identified and explained in this report. With responsible source code identified and screenshot proof of the exploit, it’s worth checking out. Ultimately, the effective payload can be seen below:

https://duckduckgo.com/50x.html?e=&atb=test%22/%3E%3Cimg%20src=x%20onerror=alert(document.domain)%3B%3E

8. Insecure Deserialisation

What is it?

To get a better sense of what Insecure Deserialisation is, we need to talk about the verb here: to serialise.

Serialisation: the process of translating an object into a format which can be persisted to disk (as a file for example), sent through streams or sent over a network. It can either be binary or structured text (such as XML, JSON etc).

Deserialisation: Well… the opposite; transforming serialised data from a file, stream or network socket into an object.

Throw insecure into the mix, and we can start to see how this can become a vulnerability. If an attacker can alter the content of what is to be deserialised, then they can leverage this to achieve remote code execution (RCE). While it is arguably the most technically complex vulnerability to exploit on the OWASP Top 10, it is usually also the most damaging when it is successful.

So…what do applications use serialisation for? There are a variety of use-cases:

• Remote-process communication (RPC) and inter-process communication (IPC).
• Wire protocols, web services and message brokers.
• Caching/persistence.
• Databases, cache servers and file systems.
• HTTP cookies, HTML form parameters and API authentication tokens.

When Does it Happen?

Fundamentally, an application is likely vulnerable to this type of attack if it deserialises untrusted or tampered data inputted from a malicious source. If these conditions exist, it can lead to two different types of exploits:

• Object/data structure-related attacks where an attacker modifies application logic or achieves RCE if there are classes available within the application that can change behaviour during or after serialisation.
• Data-tampering attacks — such as access control-related exploits where existing data structures are used but the content is modified.

How to Mitigate Insecure Deserialisation Attacks

As is written in OWASP’s guide, ‘the only safe architectural pattern is not to accept serialised objects from untrusted sources or to use serialisation mediums that only permit primitive data types’. Other mitigative steps include:

• Enforce integrity checks (i.e. digital signatures) on serialised objects to prevent hostile objects from being created or data being tampered with.
• Isolating deserialisation processes into low-privilege environments when possible.
• Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialise.
• Logging, monitoring, and alerting when a user repetitively deserialises. Given the trial-and-error nature with this type of exploit, it’s not unusual for a malicious user to be fairly noisy when attempting this style of attack.

Real-World Examples

1. In September 2018, a researcher on HackerOne identified an insecure deserialisation vulnerability in Vanilla Forums which allowed a determined attacker to achieve remote code execution. The report is extremely detailed and includes source code analysis and a PoC.
2. The same researcher (going by mr_me on HackerOne) went on to find a total of 4 exploits which all led to RCE in the Vanilla web app. The most complex of these — again with a well-written report — can be seen here.

9. Using Components with Known Vulnerabilities

In 2018, a critical vulnerability was identified in the Apache Struts 2 framework (CVE-2018–11776) with a distributed PoC.

What is it?

This one’s pretty straightforward and is exactly what it says on the tin: it is when a web app actively includes components which have publicly-disclosed vulnerabilities. Given that a web application’s components will share the privileges assigned to the app, an already-weak link can lead to severe data loss or even an entire takeover of the server.

When Does it Happen?

• If administrators are not aware of all the version info and components running on the web application.
• If software is vulnerable, unsupported or out of date.
• If routine checks are not carried out for updates and patches (whether automated or manual).

How to Avoid it

Similarly to dealing with security misconfigurations, mitigating this issue requires due diligence on behalf of those responsible for the web application. Responsibilities include:

• Removing unnecessary exposure (unused components/features/files).
• Keep an up-to-date inventory which documents every component that is used on the web application. This can then be cross-referenced against vulnerability databases (such as CVE and NVD) to identify if you have any affected components.
• Subscribe to security bulletins and e-mail notifications for relevant components that the app uses.

Real-World Example

1. You might assume that only small-scale web apps are susceptible to this type of vulnerability. However, that’s most definitely not true — and frequently-used, large-scale apps will typically have more involved components, which can increase the likelihood that one of them is vulnerable. For this first example, a fitting report was disclosed back in 2016 which affected Uber. Not only was it using an out-of-date version of WordPress, but it also ran a plugin q-and-a which had since been removed from WordPress due to having a Full Path Disclosure vulnerability. The reporter ended up identifying another vulnerability in the plugin, but was only led to it by Uber’s initial running of components with known vulnerabilities in the first place. The original report can be viewed here.

10. Insufficient Logging & Monitoring

If you’ve not been informed that your house is on fire, how will you know when it’s burning down?

What is it?

Like the previous security weakness, this one is also very straightforward. Any effective cyber security operation centre (SOC) relies extensively upon logging and monitoring to evaluate the state of the network and identify any potential threats. Failure to keep sufficient records in these areas can subsequently slow incident response, accentuating the potential damage of an intrusion. According to the OWASP Top 10, ‘most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring’.

What Constitutes Insufficient Logging & Monitoring?

• When important events such as logins, login attempts, and significant transactions are not logged.
• Warnings and errors generate no or inadequate log messages.
• Logs of applications/APIs are not kept for suspicious behaviour (i.e. mass enumeration and downloading of sensitive files on a server).
• Logs are only stored locally.
• Alerts and response escalation processes either don’t exist or are ineffective.

How to Avoid Insufficient Logging & Monitoring

• Ensure important events, significant transactions and server-side input validation failures are logged — with enough context to identify suspicious users and the ability to suspend their activity while forensic analysis takes place.
• Make sure proper access controls are enforced (such as append-only for log documents) to prevent them from being tampered with.
• Create an effective alerting system and policy which allows for potential threats to be dealt with before they escalate.

Real-World Example

November 2018 Marriott International Data Breach

Reportedly affecting more than 500 million customers, this data breach occurred following hackers gained entry to one of its 2016-acquired subsidiaries — Starwood. The vulnerable network was reported to be the guest reservation service, which attackers had been accessing since 2014. This meant that their presence went unnoticed for over four years with reports emerging in November of 2018 of the data breach. There’s no doubt that this was one of the more significant logging and monitoring failures in the history of the Internet.