OWASP Top 10 - 2021

Web Application Security Risks

https://owasp.org/www-project-top-ten/

The Open Web Application Security Project (OWASP) is an online community that produces freely available articles, methodologies, documentation, tools, and technologies in the field of web application security.

The Open Web Application Security Project (OWASP) provides free and open resources.

It is led by a non-profit called The OWASP Foundation.

The last paper  was published on 2017

The OWASP Top 10 - 2021 is the published result of recent research based on comprehensive data compiled from over 40 partner organizations.

https://en.wikipedia.org/wiki/OWASP

The OWASP document is published as an awareness document, however, organizations use it as the de facto industry AppSec standard since its inception in 2003

Agenda

1. A01- Broken Access control
2. A02 - Cryptographic Failures
3. A03 - Injection
4. A04 - Insecure Design
5. A05 - Security Misconfiguration
6. A06 - Vulnerable and Outdated Components
7. A07 - Identification and Authentication Failures
8. A08 - Software and Data Integrity Failures
9. A09 - Security Logging and Monitoring Failures
10. A10 - Server Side Request Forgery (SSRF)

2017 -> 2021 

A01 Broken Access Control

Access control enforces policy such that users cannot act outside of their intended permissions.

Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits

A01 Broken Access Control

1. Not following the deny by default principle - ppl have access to info then do not need
2. Bypassing access controls checks by modifying the URL (parameters tampering via dev tools for example)
3. Permitting viewing of modeling other users account by changing a parameter - insecure direct object reference
4. Accessing API with missing access controls for POST, PUT and DELETE
5. Elevation of privilege - acting as admin when logged as a regular user
6. Metadata manipulation - modifying JWT tokens, cookies
7. CORS misconfiguration - allowing untrusted domain to access the API

Vulnerabilities

A01 Broken Access Control

1. Except for public resources -deny by default
2. Implement access control mechanism and re-use it everywhere - use the same code/module
3. Model access controls should enforce record ownership rather than accept that the client can CURD.
4. Disable web server directory listing and inside metadata files are not present on the web root
5. Log access control failures - alert admins
6. Rate limit API and controller access to limit automatic attacks tools.
7. Stateful sessions should be invalidated on logout. Stateless JWT should be short lived

Prevention

A01 Broken Access Control

Example

A02 Cryptographic Failures

Previously known as Sensitive Data Exposure

The first thing is to determine the protection needs of data in transit and at rest.

For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, mainly if that data falls under privacy laws, e.g., EU's General Data Protection Regulation (GDPR), or regulations, e.g., financial data protection such as PCI Data Security Standard (PCI DSS)

A02 Cryptographic Failures

• Is any data transmitted in clear text?
• Are any old or weak cryptographic algorithms or protocols used either by default or in older code

• Are default crypto keys in use, weak crypto keys generated or re-used, or is proper key management or rotation missing? Are crypto keys checked into source code repositories?

• Is encryption not enforced, e.g., are any HTTP headers (browser) security directives or headers missing?

• Is the received server certificate and the trust chain properly validated?

• Are deprecated hash functions such as MD5 or SHA1 in use, or are non-cryptographic hash functions used when cryptographic hash functions are needed?

Vulnerabilities

A02 Cryptographic Failures

Prevention

• Classify data processed, stored, or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.

• Don't store sensitive data unnecessarily. Discard it as soon as possible

• Make sure to encrypt all sensitive data at rest

• Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management

• Encrypt all data in transit with security protocols such as TLS with forwarding secrecy (FS) ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption using directives like HTTP Strict Transport Security (HSTS)

• Disable caching for responses that contain sensitive data.

• More here: https://owasp.org/Top10/A02_2021-Cryptographic_Failures/

A02 Cryptographic Failures

Examples

• Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption. However, this data is automatically decrypted when retrieved, allowing a SQL injection flaw to retrieve credit card numbers in cleartext.

• Scenario #2: A site doesn't use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g., at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user's session cookie. The attacker then replays this cookie and hijacks the user's (authenticated) session, accessing or modifying the user's private data. Instead of the above they could alter all transported data, e.g., the recipient of a money transfer.

• Scenario #3: The password database uses unsalted or simple hashes to store everyone's passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted.

A03 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.

A03 Injection

• 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 (ORMs). Note: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data or executes hostile data with EXECUTE IMMEDIATE or exec().
• Use positive or "whitelist" server-side input validation.
• For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter
• Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection

Prevention

A03 Injection

Example

A04 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.

A04 Insecure Design

• Establish and use a secure development lifecycle with AppSec professionals to help evaluate and design security and privacy-related controls
• Use threat modeling for critical authentication, access control, business logic, and key flows
• Write unit and integration tests to validate that all critical flows are resistant to the threat model. Compile use-cases and misuse-cases for each tier of your application
• Segregate tier layers on the system and network layers depending on the exposure and protection needs
• Segregate tenants robustly by design throughout all tiers
• Limit resource consumption by user or service

A04 Insecure Design

Possible Attack vectors

• Scenario #1: A credential recovery workflow might include “questions and answers,” which is prohibited by NIST 800-63b, the OWASP ASVS, and the OWASP Top 10. Questions and answers cannot be trusted as evidence of identity as more than one person can know the answers
• Scenario #2: A cinema chain allows group booking discounts and has a maximum of fifteen attendees before requiring a deposit. Attackers could threat model this flow and test if they could book six hundred seats and all cinemas at once in a few requests, causing a massive loss of income
• Scenario #3: A retail chain’s e-commerce website does not have protection against bots run by scalpers buying high-end video cards to resell auction websites. This creates terrible publicity for the video card makers and retail chain owners and enduring bad blood with enthusiasts who cannot obtain these cards at any price. Careful anti-bot design and domain logic rules, such as purchases made within a few seconds of availability, might identify inauthentic purchases and rejected such transactions

A05 Security Misconfiguration

Vulnerabilites

• Missing appropriate security hardening on the cloud services
• Unnecessary features are enabled or installed (open ports, services, pages etc.).
• Default accounts and their password are active and enabled
• Error handling reveals stack track and intimate information
• System upgrades are not enabled, or security flags are off
• Using popular frameworks with security settings set to default and not enabled (Spring, Struts, Express, etc.)
• The server does not set security headers
• The software is using out dates components

A05 Security Misconfiguration

Preventions

• A repeatable hardening process
• Minimal platform
• A task to review and update system configuration
• A Segmented application architecture
• An automated process to verify the effectiveness of the configurations and settings in all environments

A05 Security Misconfiguration

Attack vectors

• Scenario #1: The application server comes with sample applications not removed from the production server. These sample applications have known security flaws attackers use to compromise the server. Suppose one of these applications is the admin console, and default accounts weren't changed
• Scenario #2: Directory listing is not disabled on the server. An attacker discovers they can simply list directories. The attacker finds and downloads the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a severe access control flaw in the application.
• Scenario #3: The application server's configuration allows detailed error messages, e.g., stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws such as component versions that are known to be vulnerable.

A06 Vulnerable and Outdated Components

Vulnerabilites

• If you do not know the versions of all components you use (both client-side and server-side)
• 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

A06 Vulnerable and Outdated Components

Preventions

• Remove unused dependencies, unnecessary features, components, files, and documentation
• Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component
• Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider deploying a virtual patch to monitor, detect, or protect against the discovered issue

A07 Identification and Authentication Failures

Vulnerabilities

• 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
• Has missing or ineffective multi-factor authentication
• Does not correctly invalidate Session IDs

A07 Identification and Authentication Failures

Preventions

• Where possible, implement multi-factor authentication to prevent automated credential stuffing, brute force, and stolen credential reuse attacks
• Do not ship or deploy with any default credentials, particularly for admin users
• Implement weak password checks, such as testing new or changed passwords against the top 10,000 worst passwords list
• Align password length, complexity, and rotation policies
• Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes
• Limit or increasingly delay failed login attempts,
• Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session identifier should not be in the URL, be securely stored, and invalidated after logout, idle, and absolute timeouts

A08 Software and Data Integrity Failures

Vulnerabilities

Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations. An example of this is where an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs). An insecure CI/CD pipeline can introduce the potential for unauthorized access, malicious code, or system compromise. Lastly, many applications now include auto-update functionality, 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. Another example is where objects or data are encoded or serialized into a structure that an attacker can see and modify is vulnerable to insecure deserialization

A08 Software and Data Integrity Failures

Preventions

• Use digital signatures or similar mechanisms to verify the software or data is from the expected source and has not been altered
• Ensure libraries and dependencies, such as npm or Maven, are consuming trusted repositories. If you have a higher risk profile, consider hosting an internal known-good repository that's vetted
• Ensure that a software supply chain security tool, such as OWASP Dependency-Check or OWASP CycloneDX, is used to verify that components do not contain known vulnerabilities
• Ensure that there is a review process for code and configuration changes to minimize the chance that malicious code or configuration could be introduced into your software pipeline
• Ensure that your CI/CD pipeline has proper segregation, configuration, and access control to ensure the integrity of the code flowing through the build and deploy processes.

A08 Software and Data Integrity Failures

Attach Vectors

• Scenario #1 Update without signing: Many home routers, set-top boxes, device firmware, and others do not verify updates via signed firmware. Unsigned firmware is a growing target for attackers and is expected to only get worse. This is a major concern as many times there is no mechanism to remediate other than to fix in a future version and wait for previous versions to age out.
• Scenario #2 SolarWinds malicious update: Nation-states have been known to attack update mechanisms, with a recent notable attack being the SolarWinds Orion attack. The company that develops the software had secure build and update integrity processes. Still, these were able to be subverted, and for several months, the firm distributed a highly targeted malicious update to more than 18,000 organizations, of which around 100 or so were affected. This is one of the most far-reaching and most significant breaches of this nature in history.

A09 Security Logging and Monitoring Failures

Vulnerabilities

• Auditable events, such as logins, failed logins, and high-value transactions, are not logged
• Warnings and errors generate no, inadequate, or unclear log messages
• Logs of applications and APIs are not monitored for suspicious activity
• Logs are only stored locally
• Appropriate alerting thresholds and response escalation processes are not in place or effective
• Penetration testing and scans by dynamic application security testing (DAST) tools (such as OWASP ZAP) do not trigger alerts

A09 Security Logging and Monitoring Failures

Preventions

• Ensure 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
• Ensure that logs are generated in a format that log management solutions can easily consume
• Ensure log data is encoded correctly to prevent injections or attacks on the logging or monitoring systems
• Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar
• DevSecOps teams should establish effective monitoring and alerting such that suspicious activities are detected and responded to quickly.
• Establish or adopt an incident response and recovery plan, such as National Institute of Standards and Technology (NIST) 800-61r2 or later

A010 Server Side Request Forgery (SSRF)

Vulnerabilities

• 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

A010 Server Side Request Forgery (SSRF)

Preventions

• From Network layer
  • Segment remote resource access functionality in separate networks to reduce the impact of SSRF
  • Enforce “deny by default” firewall policies or network access control rules to block all but essential intranet traffic.
• From Application layer
  • Sanitize and validate all client-supplied input data
  • Enforce the URL schema, port, and destination with a positive allow list
  • Do not send raw responses to clients
  • Disable HTTP redirections
  • Do not mitigate SSRF via the use of a deny list or regular expression. Attackers have payload lists, tools, and skills to bypass deny lists.

A010 Server Side Request Forgery (SSRF)

Attack Vectors

• Scenario #1: Port scan internal servers – If the network architecture is unsegmented, attackers can map out internal networks and determine if ports are open or closed on internal servers from connection results or elapsed time to connect or reject SSRF payload connections.
• Scenario #2: Sensitive data exposure – Attackers can access local files such as or internal services to gain sensitive information such as file:///etc/passwd</span> and http://localhost:28017/.
• Scenario #3: Access metadata storage of cloud services – Most cloud providers have metadata storage such as http://169.254.169.254/. An attacker can read the metadata to gain sensitive information.
• Scenario #4: Compromise internal services – The attacker can abuse internal services to conduct further attacks such as Remote Code Execution (RCE) or Denial of Service (DoS).