Synopsys sponsored this post.
Life itself is risky. There’s a seemingly endless number of ways to get hurt, sick or killed before your time. Avoiding the most dangerous risks, though, gives you a pretty good chance of living an average or better lifespan.
It’s like that in the cyber world, too. Software vulnerabilities number in the tens of thousands, and there are as many, or more, cyber criminals looking to exploit them to attack everything from the apps on smartphones to critical infrastructure — hello Colonial Pipeline and meat supplier JBS.
History of the OWASP Top 10
To paraphrase George Orwell, some vulnerabilities are much more “equal,” as in more dangerous and exploitable, than others. One of the main missions of the Open Web Application Security Project (OWASP) is to help organizations avoid the worst of those threats.
The nonprofit foundation, coming up on its 20th anniversary with hundreds of local chapters and tens of thousands of members worldwide, does that in multiple ways, including education programs and conferences. One of the most visible is its iconic OWASP Top 10 list of the most critical risks to web applications, recently updated for the first time in four years. It includes three new categories, plus some position shifts among those that remain.
The OWASP website offers considerable detail on each vulnerability, including a description, why it ranks where it does, possible attack scenarios, and how to fix or mitigate those vulnerabilities. A summary of the list follows. All quotations, unless otherwise noted, are from the OWASP website.
1. Broken Access Control
This vulnerability moved from fifth to first place, with more occurrences in applications than any other category in the contributed dataset at more than 318,000.
As the name implies, it refers to a failure to implement the principle of least privilege — limiting access to data only to those who are authorized and who need it to do their jobs. It can “lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside the user’s limits.”
Among the ways to prevent it are denial by default, implementing access-control mechanisms once and reusing them throughout the application, and enforcing record ownership rather than accepting that the user can create, read, update or delete any record. Finally, keep a log of access failures and alert administrators in the event of repeated failures.
2. Cryptographic Failures
This was previously called “sensitive data exposure,” and moved from third to second on the list, which means organizations are still, perhaps increasingly, risking exposure of data by failing to encrypt it. Generally, data needs to be encrypted both at rest and in transit, especially passwords, credit card numbers, health records, personal information and business secrets, which can be governed by privacy laws or financial data protection regulations.
Among possible attack scenarios, cryptographic security weaknesses present possible exploitation opportunities that administrators and developers should be aware of. An application that encrypts credit card numbers in a database, but decrypting the data automatically when retrieved allows an SQL injection attack to retrieve credit card numbers in clear text.
The solution should be obvious: Use rigorous encryption on all data at risk. Don’t transmit anything in clear text. Start by classifying what is sensitive according to privacy laws, regulatory requirements or business needs.
To encrypt sensitive data at rest, ensure up-to-date and strong standard algorithms, protocols and keys are in place, and use proper key management. All data in transit should be encrypted with secure protocols such as transport layer security (TLS) with forward secrecy ciphers, cipher prioritization by the server and secure parameters. Enforce encryption using directives like HTTP Strict Transport Security.
Check to make sure you’re not using old or weak cryptographic algorithms or protocols by default or in older code.
Enforce your encryption policies. Perhaps most importantly, don’t store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS-compliant tokenization or even truncation. Data that isn’t retained can’t be stolen.
This dropped from second to third. It refers to vulnerabilities that allow attackers to inject malicious code into the network that then gets processed by an interpreter as part of a command or query, resulting in information sent to an attacker from the database.
An example is user-supplied data that isn’t validated, filtered or sanitized by the application, which can lead to data theft, data loss, loss of data integrity, denial of service and full-system compromise.
Among the ways to prevent injection is to keep data separate from commands and queries. The preferred option is to use a safe API, which avoids using the interpreter entirely, provides a parameterized interface or migrates to object relational mapping tools.
4. Insecure Design
A new category for 2021, it amounts to the digital version of designing a building with architectural flaws that could lead to everything from a roof leaking to a catastrophic foundation collapse. Some applications are not designed according to security best practices.
“As a community we need to move beyond ‘shift-left’ in the coding space to precode activities that are critical for the principles of secure by design,” OWASP said, noting also that it’s important not to conflate design flaws with implementation flaws.
“A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation, as by definition needed security controls were never created to defend against specific attacks.”
Secure design is a method that “constantly evaluates threats and ensures that code is robustly designed and tested to prevent known attack methods.”
Among the multiple ways to prevent insecure design, the first on the list is probably the most important: “Establish and use a secure development life cycle with [the help of] AppSec professionals to evaluate and design security and privacy-related controls.”
5. Security Misconfiguration
This moved from sixth to fifth place, with more than 208,000 occurrences of a common weakness enumeration, which are coding defects that create vulnerabilities within software. “With more shifts into highly configurable software, it’s not surprising to see this category move up.”
Examples of this vulnerability include:
- Enabling or installing unnecessary features such as ports, services, pages, accounts or privileges.
- Default accounts with passwords still enabled and unchanged.
- Software that’s out of date or vulnerable.
Prevention measures include using automation to make sure that development, QA and production environments are all configured identically, with different credentials used in each environment. Also helpful is a minimal platform without unnecessary features, components, documentation and samples. Essentially, remove or don’t install unused features and frameworks. Criminals can’t attack what you don’t have.
6. Vulnerable and Outdated Components
This category, previously called “using components with known vulnerabilities,” rose from ninth to sixth and ranked No. 2 in the OWASP Top 10 community survey.
It should be obvious that organizations are vulnerable if they don’t know everything about all software components they use including versions, known vulnerabilities and whether they are unsupported or out of date. This includes software running the operating system, web/application server, database management system, applications, APIs and all components, runtime environments, and libraries. It also includes not just components you use directly, but nested dependencies as well.
Tim Mackey, principal security strategist within the Synopsys Cybersecurity Research Center, has noted that a single component in an application could easily have a web of more than 100 dependencies when you “peel the onion” of the software supply chain.
The most effective way to start eliminating that vulnerability is to maintain a software inventory, otherwise known as a software bill of materials (SBOM). A common slogan at security conferences is, “You can’t protect what you don’t know you have.” One of the best ways to maintain that inventory, given that the majority of the components in software projects are open source, is with an automated software composition analysis (SCA) tool, which helps find open source components and will let you know if there are known vulnerabilities or licensing conflicts.
To avoid these vulnerabilities, at a minimum, maintain an SBOM and have a patch management process to remove unused dependencies, unnecessary features, components, files and documentation.
7. Identification and Authentication Failures
This category, previously called “broken authentication,” dropped from second to seventh on the list. It refers to software defects that:
- Permit automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
- Allow default, weak or well-known passwords such as “password1” or “admin/admin.”
- Allow the use of weak or ineffective credential recovery and forgot-password processes, such as “knowledge-based answers.”
- Have missing or ineffective multifactor authentication.
Prevention measures include requiring multifactor authentication, not shipping products with default credentials and implementing checks for weak passwords.
8. Software and Data Integrity Failure
This vulnerability, new to the OWASP Top 10 list, is caused by making assumptions related to software updates or critical data without verifying their integrity.
One of the more recent examples is the auto-update function in many applications where “updates are downloaded without sufficient integrity verification and applied to the previously trusted application. Attackers could potentially upload their own updates to be distributed and run on all installations.”
One of the most recent exploitations of that vulnerability was against Texas-based SolarWinds earlier this year. Attackers, believed to be from Russian intelligence, were able to slip malware into an update of the company’s network management system, a software program called Orion, so that when customers installed the update, they also installed the malware.
That means updates and patches must be vetted. OWASP recommends, among other things, using digital signatures or similar mechanisms to verify the software or data is from the expected source and was not altered. Also use a software supply chain security tool, such as OWASP Dependency Check or OWASP CycloneDX to verify that components don’t contain known vulnerabilities.
9. Security Logging and Monitoring Failures
This moved up one notch, from tenth to ninth, and while OWASP said it isn’t well represented in the known vulnerability data, “it can be very impactful for accountability, visibility, incident alerting and forensics.” It elevates risk because “without logging and monitoring, breaches cannot be detected.”
Depending on the risk of the application, controls should include, at a minimum, ensuring that “all login, access control and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts and held for enough time to allow delayed forensic analysis.”
Of course, DevSecOps teams need to conduct effective monitoring so they can detect and respond quickly to any suspicious activity.
10. Server-side Request Forgery (SSRF)
This wouldn’t have made the OWASP Top 10 based on OWASP data collection, which showed a relatively low incidence rate. However, “security community members are telling us this is important, even though it’s not illustrated in the data at this time.”
This defect means that a web application “is fetching a remote resource without validating the user-supplied URL. It allows an attacker to persuade the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN or another type of network access control list.”
OWASP said both the incidence and severity of SSRF attacks are increasing “due to cloud services and the complexity of architectures.”
There are a number of ways to prevent SSRF. At the network layer, OWASP recommends segmenting remote resource access functionality in separate networks and enforcing “deny by default” firewall policies or network access control rules to block all but essential intranet traffic.
At the application level, “sanitize and validate all client-supplied input data and enforce the URL schema, port and destination with a positive allow list. Just don’t try to block attackers with a deny list or regular expression because “attackers have payload lists, tools and skills to bypass deny lists.”
Avoid Being an Easy Target
Addressing everything on the list won’t make an organization bulletproof. Nothing will. OWASP doesn’t claim it will. Though it will make those who do so a much more difficult target. Most attackers are looking for easy targets.
Photo by David Hablützel from Pexels.