...
A03:2021 – Injection
An application is vulnerable to attack when:
· User-supplied data is not validated, filtered, or sanitized by the application.
· Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter.
· Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.
· Hostile data is directly used or concatenated. The SQL or command contains the structure and malicious data in dynamic queries, commands, or stored procedures.
Some of the more common injections are SQL, NoSQL, OS command, Object Relational Mapping (ORM), LDAP, and Expression Language (EL) or Object Graph Navigation Library (OGNL) injection. The concept is identical among all interpreters. Source code review is the best method of detecting if applications are vulnerable to injections. Automated testing of all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs is strongly encouraged. Organizations can include static (SAST), dynamic (DAST), and interactive (IAST) application security testing tools into the CI/CD pipeline to identify introduced injection flaws before production deployment.
A04:2021 – Insecure Design
Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design.” Insecure design is not the source for all other Top 10 risk categories. There is a difference between insecure design and insecure implementation. We differentiate between design flaws and implementation defects for a reason, they have different root causes and remediation. 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. One of the factors that contribute to insecure design is the lack of business risk profiling inherent in the software or system being developed, and thus the failure to determine what level of security design is required.
Requirements and Resource Management
Collect and negotiate the business requirements for an application with the business, including the protection requirements concerning confidentiality, integrity, availability, and authenticity of all data assets and the expected business logic. Take into account how exposed your application will be and if you need segregation of tenants (additionally to access control). Compile the technical requirements, including functional and non-functional security requirements. Plan and negotiate the budget covering all design, build, testing, and operation, including security activities.
Secure Design
Secure design is a culture and methodology that constantly evaluates threats and ensures that code is robustly designed and tested to prevent known attack methods. Threat modeling should be integrated into refinement sessions (or similar activities); look for changes in data flows and access control or other security controls. In the user story development determine the correct flow and failure states, ensure they are well understood and agreed upon by responsible and impacted parties. Analyze assumptions and conditions for expected and failure flows, ensure they are still accurate and desirable. Determine how to validate the assumptions and enforce conditions needed for proper behaviors. Ensure the results are documented in the user story. Learn from mistakes and offer positive incentives to promote improvements. Secure design is neither an add-on nor a tool that you can add to software.
Secure Development Lifecycle
Secure software requires a secure development lifecycle, some form of secure design pattern, paved road methodology, secured component library, tooling, and threat modeling. Reach out for your security specialists at the beginning of a software project throughout the whole project and maintenance of your software. Consider leveraging the OWASP Software Assurance Maturity Model (SAMM) to help structure your secure software development efforts.
A05:2021 – Security Misconfiguration
The application might be vulnerable if the application is:
· Missing appropriate security hardening across any part of the application stack or improperly configured permissions on cloud services.
· Unnecessary features are enabled or installed (e.g., unnecessary ports, services, pages, accounts, or privileges).
· Default accounts and their passwords are still enabled and unchanged.
· Error handling reveals stack traces or other overly informative error messages to users.
· For upgraded systems, the latest security features are disabled or not configured securely.
· The security settings in the application servers, application frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc., are not set to secure values.
· The server does not send security headers or directives, or they are not set to secure values.
· The software is out of date or vulnerable (see A06:2021-Vulnerable and Outdated Components).
Without a concerted, repeatable application security configuration process, systems are at a higher risk.
A06:2021 – Vulnerable and Outdated Components
You are likely vulnerable:
· If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies.
· If the software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.
· If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use.
· If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, leaving organizations open to days or months of unnecessary exposure to fixed vulnerabilities.
· If software developers do not test the compatibility of updated, upgraded, or patched libraries.
· If you do not secure the components’ configurations (see A05:2021-Security Misconfiguration).
A07:2021 – Identification and Authentication Failures
Confirmation of the user's identity, authentication, and session management is critical to protect against authentication-related attacks. There may be authentication weaknesses if the application:
· Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
· Permits brute force or other automated attacks.
· Permits default, weak, or well-known passwords, such as "Password1" or "admin/admin".
· Uses weak or ineffective credential recovery and forgot-password processes, such as "knowledge-based answers," which cannot be made safe.
· Uses plain text, encrypted, or weakly hashed passwords data stores (see A02:2021-Cryptographic Failures).
· Has missing or ineffective multi-factor authentication.
· Exposes session identifier in the URL.
· Reuse session identifier after successful login.
· Does not correctly invalidate Session IDs. User sessions or authentication tokens (mainly single sign-on (SSO) tokens) aren't properly invalidated during logout or a period of inactivity.
A8:2021 – Server-Side Request Forgery (SSRF)
SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce 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 (ACL).
As modern web applications provide end-users with convenient features, fetching a URL becomes a common scenario. As a result, the incidence of SSRF is increasing. Also, the severity of SSRF is becoming higher due to cloud services and the complexity of architectures.