According to the U.S Department of Commerce, e-commerce sales in the first quarter of 2022 accounted for 14.3% of total sales. Secure web applications are essential for modern retailers, but many are still struggling to combat common web application risks, including ones such as cross-site scripting and code injection that have been around for years, consistently making the OWASP list of top ten web application risks.
The Open Web Application Security Project (OWASP) is a nonprofit foundation dedicated to promoting software security. The OWASP Top 10 provides a list of the ten most critical web application security risks, which can be used as a checklist for security teams and auditors alike to gauge the maturity of a security program. The list has had iterations released every few years since 2003, with the most recent being released in 2021. Looking at that first list, there is a remarkable level of similarity between it and its newest counterpart. Broken access control was number two on the 2003 list and is number one on the 2021 list. Cross-site scripting, broken authentication, and injection flaws also have withstood the test of time, continuing to make the list.
This post reviews the 2021 OWASP Top 10 and provides suggestions for mitigation.
A1 Broken Access Control: Broken access control started as number two on the list in 2003 but disappeared in subsequent lists, only to resurface in 2017 as number five and is now in the top spot. Why? Well, first, let’s look at what broken access control is. Access controls are what prevent users from acting outside of their given permissions. However, if there are vulnerabilities in these controls, they can be exploited to gain access to resources and actions that should be restricted.
This can be broken down into two main categories, horizontal privilege escalation and vertical privilege escalation.
Vertical privilege escalation is when a user acquires permissions above what they would normally have access to. This can occur through unprotected functionality, such as when a user can access the admin panel by modifying the URL and checking the robots.txt or parameter-based access control where the privilege level is hidden in a form field, cookie, or query string parameter, and the attacker can add the parameter to gain privileges.
Horizontal access escalation is when a user can access data or perform actions of another user of the same permission level. For example, a user can modify the id parameter to access someone else’s account. Typically, it won’t be as simple as just guessing another number, as most applications will be using a globally unique identifier (GUID), however, users’ GUIDs could be leaked or hidden somewhere in the application.
We’ve always needed some way to control what a user has access to, and attackers are always going to try to gain more privileges than they should have, which is why this threat has been around so long, but the reason for its resurgence now may be due to the introduction of more complex security protocols such as OAuth 2.0, OpenID Connect, and SAML. Applications are no longer simply relying on HTTP basic authentication. Authentication is taking place across hybrid environments with a variety of IAM solutions causing integration challenges. Web APIs, which are being used more frequently, are also prone to access insecurities, leading to more instances of this vulnerability. Access has once again become difficult to manage, bringing it back to the top of the list.
A couple of tips for preventing access control vulnerabilities:
- Don’t depend on obfuscation alone for access control.
- Employ the principle of least privilege, providing only the access needed and denying access by default.
- Use role-based access control to group users and decide permissions for each role group.
- Use a single application-wide mechanism for enforcing access controls if possible.
- Perform penetration testing, as vulnerability scanners will not always be able to detect broken access control.
- Ensure all requests go through an access control verification layer.
- Limit the use of cross-origin resource sharing (CORS) and ensure correct configuration where used. Misconfiguration of a CORS policy can allow an attacker to use cross-domain authenticated requests to steal data from your web application.
A2 Cryptographic Failures: Cryptographic failures were previously categorized on the list as sensitive data exposure, which makes sense since that is the end result of a cryptographic failure. Data exposure can occur when you store or move data in clear text, protect data with old or weak encryption, or improperly filter or mask data while in transit. Cryptographic failures can be prevented by using proper encryption practices, key management, and data storage policies. Don’t use legacy protocols such as FTP and SMTP for transporting sensitive data, and store passwords using strong adaptive and salted hashing functions.
A3 Injection: Remote code execution, also known as code injection, allows a threat actor to remotely execute any code of their choice over LAN, WAN, or internet. For example, dynamic SQL injection allows an attacker to inject malicious SQL query commands into input fields, if they are not vetted, which will allow the attacker to access database information. Similarly, cross-site scripting, which used to be its own separate list line item, but was this year combined with injection, utilizes injection to perform a similar operation, except that the injected scripts are run on the client-side, and the scripts used are JavaScript as opposed to query. Avoid code injection vulnerabilities by validating and sanitizing inputs, avoiding vulnerable evaluation constructs, and locking down your interpreter.
A4 Insecure Design: Insecure design is a completely new addition to the 2021 list, which refers to a lack of security strategy in the design of the application. This is different from an insecure implementation, which might mean bugs in the code. Insecure design would not be a few application security vulnerabilities; it would be a lack of overarching security planning that leaves the application vulnerable. This is likely being added now as the industry adopts the “shifting security left” mindset. Previously, security may have been addressed after an application was built, however, security is now shifting left in the development process to be included from the outset. Before an application is developed, business risk profiling must be done to determine the protection requirements needed.
A5 Security Misconfiguration: This category combines security misconfigurations as well as XML external entities from the 2017 list. XML external entities can be rolled up into this broader category as it involves XML input processed by a weakly configured XML parser. Misconfigurations aren’t new. Its predecessor, insecure configuration management, made the 2003 list. As long as there are settings set by humans, there will be misconfigurations. However, misconfigurations are becoming an area of focus now as teams transition to the cloud where configurations are extensive, and mistakes can easily expose data to the open internet. Learn more about cloud security configurations in RH-ISAC’s blog post, Mitigate Compliance Risks with Cloud Security Posture Management (CSPM).
A6 Vulnerable and Outdated Components: This is up from number nine on the 2017 list, then titled “using components with known vulnerabilities.” As organizations prioritize continuous integration and deployment in application development, more and more developers are turning to third-party code libraries to handle routine functions. These components save time, but often contain vulnerabilities and can quickly become outdated if the original provider is no longer maintaining them.
A7 Identification and Authentication Failures: Authentication is another problem that has plagued developers since the dawn of the OWASP list. This has dropped from number two in 2017 to number seven on this new list, which hopefully indicates that efforts such as requiring users to generate stronger passwords and use multi-factor authentication are working. There are also static analysis tools that can detect authentication vulnerabilities during the development process to help prevent these vulnerabilities from making it into production.
A8 Software and Data Integrity Failures: This a new category, but it does include within it insecure deserialization from the 2017 list. This is similar to insecure design in that it is an indictment of an element of the development process. It refers to failures in code or infrastructure that don’t protect against integrity violations. Essentially this would include allowing auto-updates that aren’t verified, relying on plugins or modules from untrusted sources or content delivery networks (CDN), or not using digital signatures to verify that data hasn’t been altered. In other words, there has been an oversight in the CI/CD pipeline that has introduced an opportunity for vulnerability.
A9 Security Logging and Monitoring Failures: This is a tough one to define as a risk because there aren’t a lot of CVEs directly associated with it, but logging and monitoring are essential to be able to detect suspicious behavior such as repeated failed login attempts. Failures can decrease response times in the event of a breach, as warning signs of compromise can be missed.
A10 Server-Side Request Forgery: This is a completely new category for 2021, which had a relatively low incidence rate, but an above-average exploit and impact rating in the OWASP survey, which is why it was added to the list, though OWASP indicates it may be rolled into a broader category in the future. Server-side request forgery bypasses protections such as firewalls and VPNs using a user-supplied URL that is not validated before fetching the requested resource from the server. This can provide dangerous access to internal resources as well as credentials. These attacks have become more prevalent with the rise of cloud computing. Server meta data, which can be used to configure a public cloud instance, can be accessed via a URL that is normally only accessible from the server. If an attacker launches a server-side request forgery attack, they can gain access to whatever resources are allowed by the privileges granted to the token. Cloud service providers attempt to prevent this by requiring inclusion of a specific header with the request; however, this has not been able to prevent all instances of the attack. Other SSRF mitigation tactics include enforcing “deny by default” firewall policies and sanitizing and validating all client-supplied input data.
RH-ISAC members have access to a community of cybersecurity professionals who share identified attempted exploits and can provide advice for strengthening your applications against these common vulnerabilities. Not an RH-ISAC member? Learn more about how being a part of the RH-ISAC’s member community can benefit you.
