The following blog post was written by our friends at AppCheck.
OWASP (Open Web Application Security Project) is an organisation providing unbiased information and advice surrounding computer and internet applications.
Every few years the OWASP community come together to review the ten most critical web application security risks (commonly known simply as the “OWASP Top 10”) by analysing vulnerability data spanning hundreds of organisations and over 100,000 real-world applications. This process was most recently performed in 2021 and a new, updated top 10 list was published. The vulnerabilities are assessed by OWASP using several factors such as detectability, exploitability, and potential impact to create the final list.
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 is that if controls and measures such as security training cover only vulnerabilities listed in the OWASP Top 10, and go no further, an organisation may consider web application security to be “mission complete”, despite the vulnerabilities covered representing just a tiny fraction of those observed.
Best practice advice from OWASP 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 hasn't considered that provide critical threats to their web estate.
We'll be picking a few of the critical, interesting, or even just plain bizarre vulnerabilities that are not included in the Top 10 and see how they could impact your business.
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 the 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 is to use these themselves only, and 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 is 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.
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 values.
Variants can include multiple cookies with the same name, 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.
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 the inability to handle variations including character case, word boundaries and special chars, or performing overly “greedy” matches.
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.
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 blog 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.
Logged under CWE-362, Race Conditions occur when a sequence of actions happens 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:
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
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.
The last example highlights that a vulnerability doesn’t have to be technically complex, and a developer may be aware of the vulnerability existing, yet not consider it to be a vulnerability. One such example 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 is 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.
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 and intentionally submitted by the application rather than being automatically included.
Cantarus is a proud AppCheck Partner
If you’d like to know more about AppCheck you can visit their website, or get in touch with us at [email protected] to learn more.
