The OWASP Top 10 provides a standardized catalog of the most critical security risks to web applications. Compiled by a global community of security experts, this influential document highlights the most prevalent vulnerabilities that organizations must address. To mitigate these risks effectively, OWASP encourages widespread adoption of the Top 10 as a foundational element of secure software development lifecycle (SDLC) practices. Below are the security risks reported in the OWASP 2021 report.

These are the top categories in the OWASP-2021 report, you can gain some in-depth knowledge of these categories.

1. Broken Access Control

Access control is a security mechanism that restricts user actions to authorized boundaries. Enforcing granular permissions safeguards sensitive information from unauthorized disclosure, modification, or destruction. Access control failures can lead to data breaches, privilege escalation, and business process compromises. Common access control vulnerabilities include:

• Violation of the principle of least privilege or deny by default, where access should be granted only to specific capabilities, roles, or users, but is instead available to anyone.
• Bypassing access control checks by modifying the URL (parameter tampering or force browsing), altering the internal application state, or changing the HTML page, often using an attack tool to modify API requests.
• Accessing APIs without proper access controls for POST, PUT, and DELETE operations.
• Elevation of privilege. Acting as a user without being logged in or performing admin functions while logged in as a standard user.
• CORS misconfiguration permits API access from unauthorized or untrusted origins.
• Unauthorized access to authenticated pages as an unauthenticated user or to privileged pages as a standard user through forceful browsing.

Preventions:

• Restrict access by default, allowing only public resources.
• Implement access control mechanisms once and reuse them throughout the application, minimizing the use of Cross-Origin Resource Sharing (CORS).
• Enforce unique application business limit requirements through domain models.
• Log access control failures and notify administrators when necessary.
• Rate limits API and controller access to minimize the impact of automated attack tools.

Examples: 

Scenario #1: The application uses unverified data in a SQL query to access account information.

pstmt.setString(1, request.getParameter("acct"));
 ResultSet results = pstmt.executeQuery( );

An attacker can modify the browser’s ‘acct’ parameter to submit any account number. Without proper verification, this allows access to any user’s account.

https://example.com/app/accountInfo?acct=notmyacct

Scenario #2: An attacker attempts to forcefully browse to target URLs. Admin rights are required to access the admin page.

https://example.com/app/admin_getappInfo

If an unauthenticated user can access either page, it’s a security flaw. If a non-admin can access the admin page, it also indicates a flaw.

Reference: https://owasp.org/Top10/A01_2021-Broken_Access_Control/

2. Cryptographic Failures

The initial step in data protection is to assess the sensitivity of information both at rest and in transit. Data categories such as passwords, financial data, personal identifiable information (PII), and trade secrets demand heightened security measures, especially when subject to stringent regulatory frameworks like the General Data Protection Regulation (GDPR) or the Payment Card Industry Data Security Standard (PCI DSS).

Common Causes of Cryptographic Failures:

• Weak algorithms: Using outdated or insecure cryptographic algorithms.
• Improper key management: Generating, storing, and using cryptographic keys incorrectly.
• Incorrect implementation: Making errors in the code that implements cryptographic functions.
• Lack of validation: Not verifying the integrity and authenticity of data.
• Insufficient randomness: Using weak random number generators for key generation.

Preventions:

• Classify data processed, stored, or transmitted by an application, identifying sensitive information according to privacy laws, regulatory requirements, or business needs.
• Encrypt all sensitive data at rest to protect it from unauthorized access.
• Use up-to-date and robust algorithms, protocols, and encryption keys, and implement proper key management practices.
• Disable caching for responses that contain sensitive data to prevent unauthorized access.
• Apply security controls based on data classification to ensure appropriate protection measures.
• Avoid using legacy protocols like FTP and SMTP for transmitting sensitive data to prevent security vulnerabilities.
• Store passwords using strong, adaptive, and salted hashing functions with a work factor, such as Argon2, scrypt, bcrypt, or PBKDF2, to enhance security.

Examples:

Scenario 1: Encryption Inconsistency Despite database encryption, sensitive data like credit card numbers may be exposed through vulnerabilities like SQL injection if decrypted prematurely during application retrieval. This highlights the importance of end-to-end encryption.

Scenario 2: Weak Transport Layer Security (TLS) A lack of robust TLS implementation can leave applications susceptible to man-in-the-middle attacks. By intercepting unencrypted traffic, adversaries can steal session cookies, hijack user sessions, and manipulate data in transit, potentially leading to unauthorized access or financial loss.

Reference: https://owasp.org/Top10/A02_2021-Cryptographic_Failures/

3. Injection attacks

Injection is a broad category of security vulnerabilities that occur when untrusted data is sent to an interpreter as part of a command or query. The interpreter then processes the input without proper validation, leading to unintended consequences such as data loss, system compromise, or denial of service.

Common Types of Injection Attacks:

While the core principle of injection attacks remains consistent, they manifest in various forms depending on the target system or application:

1. SQL Injection: Exploits vulnerabilities in SQL databases by injecting malicious SQL statements.

• Impact: Unauthorized data access, modification, or deletion; data exfiltration; denial of service.
• Example: An attacker might inject malicious SQL code into a login form to bypass authentication or retrieve sensitive information.

2. OS Command Injection: Allows attackers to execute operating system commands through the application.

• Impact: System compromise, data theft, denial of service.
• Example: An attacker might inject malicious commands into a search field to execute arbitrary commands on the server.

3. LDAP Injection: Targets Lightweight Directory Access Protocol (LDAP) servers by injecting malicious LDAP queries.

• Impact: Unauthorized access to directory information, denial of service.
• Example: An attacker might inject malicious LDAP queries to bypass authentication or enumerate user information.

4. XML Injection: Exploits vulnerabilities in XML processors by injecting malicious XML content.

• Impact: Data exposure, denial of service, server-side request forgery (SSRF).
• Example: An attacker might inject malicious XML code into a web application to modify XML data or execute arbitrary code.

5. NoSQL Injection: Targets NoSQL databases by injecting malicious queries.

• Impact: Unauthorized data access, modification, or deletion.
• Example: An attacker might inject malicious queries into a NoSQL database, such as MongoDB, to access sensitive data or alter the database structure.

Preventions:

• Implement positive server-side input validation. While this measure is crucial, it may not be comprehensive as many applications, including text areas or mobile application APIs, require the use of special characters.
• The preferred approach is to use a secure API that avoids direct interaction with the interpreter, offers a parameterized interface, or transitions to Object-Relational Mapping (ORM) tools to mitigate injection risks.
• Utilize SQL controls such as LIMIT within queries to prevent the mass disclosure of records in the event of an SQL injection attack.

Examples:

Scenario #1: The application constructs the following vulnerable SQL query using untrusted data:

String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Scenario #2: Similarly, an application’s blind trust in frameworks can lead to queries that remain vulnerable, such as those written in Hibernate Query Language (HQL): 

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

In both scenarios, the attacker alters the ‘id’ parameter in their browser to send: ‘ UNION SLEEP(10);–.

This modification changes the intent of both queries, causing them to return all records from the accounts table. More severe attacks could involve modifying or deleting data, or even executing stored procedures.

Reference: https://owasp.org/Top10/A03_2021-Injection/

4. Insecure Designs

Insecure design refers to fundamental flaws in a system’s architecture, characterized by missing or ineffective security controls. Unlike insecure implementation, which involves errors in executing a design, insecure design stems from inadequate risk profiling and fails to address specific attack vectors. Even a flawless implementation cannot fix an insecure design, as essential security controls were never established.

Insecure design is about neglecting security as a first-class citizen in the development process. It manifests in various ways:

1. Lack of Threat Modeling: Failing to identify potential threats and vulnerabilities early in the development lifecycle can leave systems vulnerable to attacks.
2. Poor Architectural Decisions: Design choices that introduce inherent security risks, such as monolithic architectures that are hard to secure or overly complex systems that expand the attack surface.
3. Insufficient Input Validation and Sanitization: Not properly validating and sanitizing user-supplied data, leading to vulnerabilities such as SQL injection and cross-site scripting (XSS).
4. Weak Authentication and Authorization: Implementing inadequate mechanisms for verifying user identity and controlling access, which can lead to unauthorized access.
5. Insecure Session Management: Failing to secure user sessions, resulting in vulnerabilities like session hijacking and impersonation.
6. Cryptography Blunders: Misusing cryptographic algorithms or keys, which can result in data breaches.
7. Error Handling Flaws: Exposing sensitive information through error messages or exceptions.

Preventions:

• Establish and Utilize a Library of Secure Design Patterns: Create and use a repository of secure design patterns or pre-approved components to ensure consistent security practices.
• Apply Threat Modeling: Implement threat modeling for critical areas such as authentication, access control, business logic, and key workflows.
• Integrate Plausibility Checks: Incorporate plausibility checks at every tier of your application, from the frontend to the backend, to validate data and operations.
• Conduct Unit and Integration Tests: Write unit and integration tests to ensure all critical flows are resilient to identified threats. Develop use cases and misuse cases for each tier of the application.
• Segregate System and Network Layers: Separate system and network layers based on exposure and protection needs to enhance security.
• Limit Resource Consumption: Restrict resource usage by users or services to prevent abuse and potential denial-of-service attacks.

Examples:

Scenario #1: A credential recovery process that relies on “questions and answers” is not compliant with NIST 800-63b, the OWASP ASVS, or the OWASP Top 10. These methods are unreliable for verifying identity because multiple individuals could potentially know the answers. This approach should be removed and replaced with a more secure design.

Scenario #2: A cinema chain offers group booking discounts and requires a deposit for bookings exceeding fifteen attendees. Attackers could exploit this system by threat modeling the process to book six hundred seats across all cinemas in just a few requests, potentially resulting in significant financial loss.

Reference: https://owasp.org/Top10/A04_2021-Insecure_Design/

5. Security Misconfiguration

Security misconfiguration is a broad category of vulnerabilities that arise from improper configuration of system hardware, software, and applications. Essentially, it’s like leaving a door unlocked or a window open, inviting unauthorized access. Misconfiguration can manifest in various forms across different IT components.

Network Devices: Issues include incorrect firewall rules, open ports, weak authentication, and improper network segmentation.

Servers: Problems arise from default configurations, weak passwords, missing patches, permissive file permissions, and insecure services.

Databases: Vulnerabilities include default credentials, weak encryption, exposed management interfaces, and excessive database privileges.

Applications: Security risks stem from insecure default settings, improper error handling, missing input validation, and weak session management.

Cloud Services: Challenges include incorrect access controls, misconfigured storage bucket permissions, network security group misconfigurations, and data exposure.

Preventions:

• Establish secure baseline configurations for systems and applications.
• Conduct regular vulnerability assessments and penetration testing.
• Keep systems and applications updated with the latest patches.
• Provide users and applications with only the necessary permissions.
• Educate employees on the importance of secure configurations.
• Challenges include incorrect access controls, misconfigured storage bucket permissions, network security group misconfigurations, and data exposure.

Examples:

Scenario #1: The application server includes sample applications that were not removed from the production environment. These sample applications contain known security vulnerabilities that attackers can exploit. For example, if one of these applications is an admin console with unchanged default accounts, an attacker can log in using default passwords and gain control.

Scenario #2: Directory listing is enabled on the server. An attacker can easily list directories and discover the compiled Java classes. By downloading and decompiling these classes, the attacker reverse engineers the code and identifies a critical access control flaw in the application.

Reference: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/

6. Vulnerable and Outdated Components

Vulnerable and outdated components refer to third-party software, libraries, or frameworks used within an application that contain known security vulnerabilities or are no longer supported by their developers. These components can be either open-source or proprietary.

Prevention:

Modern applications are increasingly composed of a complex web of interconnected components. This ecosystem includes:

1. Open-source Libraries: Reusable code modules that offer specific functionalities.
2. Frameworks: Software platforms that serve as a foundation for developing applications.
3. Operating Systems: The fundamental software that manages both hardware and software resources.
4. Application Servers: Software that manages and serves web applications.
5. Databases: Software for storing and managing data.
6. APIs: Interfaces that enable different software components to communicate.

Each of these components may have dependencies on other components, creating a complex dependency tree.

Examples:

Scenario #1: Component Privileges and Vulnerabilities

Components typically run with the same privileges as the application itself, so flaws in any component can lead to significant security impacts. These flaws can be accidental, such as coding errors, or intentional, such as backdoors embedded in a component. Some examples of exploitable component vulnerabilities include:

• CVE-2017-5638: A Struts 2 remote code execution vulnerability that allows arbitrary code execution on the server, which has been linked to significant data breaches.

Patching is crucial for all systems, including Internet of Things (IoT) devices, which are often difficult or impossible to update. The importance of patching IoT devices, such as biomedical equipment, cannot be overstated.

Attackers often use automated tools to locate unpatched or misconfigured systems. For instance, the Shodan IoT search engine can identify devices still vulnerable to the Heartbleed bug, which was patched in April 2014.

Reference: https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/

7. Identification and Authentication Failures

Identification and authentication failures occur when a system or application is unable to accurately verify a user’s identity, leading to unauthorized access. This fundamental security lapse can have severe consequences for organizations.

• Identification: Establishing a user’s claimed identity, usually through a username, email address, or other unique identifier.
• Authentication: Verifying the claimed identity, often through a password, biometric data, or a combination of factors.

Both processes are crucial for maintaining system security. A failure in either can lead to breaches.

Types Of Failures:

• Allows Automated Attacks: Enables credential stuffing attacks, where attackers use lists of valid usernames and passwords.
• Allows Brute Force Attacks: Permits brute force or other automated attack methods.
• Permits Weak Passwords: Allows the use of default, weak, or well-known passwords, such as “Password1” or “admin/admin”.
• Insecure Password Storage: Uses plain text, encrypted, or weakly hashed password data stores.
• Exposes Session Identifiers: Exposes session identifiers in the URL, increasing the risk of session hijacking.
• Session Reuse: Reuses session identifiers after successful login, compromising session security.
• Improper Session Invalidation: Fails to correctly invalidate session IDs, including user sessions or authentication tokens (especially single sign-on (SSO) tokens), during logout or periods of inactivity.

Prevention:

• Wherever possible, implement multi-factor authentication (MFA) 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 a list of the top 10,000 passwords.
• Ensure registration, credential recovery, and API pathways are protected against account enumeration attacks by using uniform messages for all outcomes.
• Limit or increasingly delay failed login attempts to thwart brute force attacks, but avoid creating denial of service scenarios. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.

Examples:

Scenario #1: Credential stuffing, which involves using lists of known passwords, is a prevalent attack method. If an application lacks automated protection against such attacks, it can be exploited as a password oracle to verify the validity of credentials.

Scenario #2: Many authentication attacks result from relying solely on passwords. While password rotation and complexity requirements were once considered best practices, they often lead to the use of weak or reused passwords. Organizations should follow NIST 800-63 guidelines and transition to multi-factor authentication to enhance security.

Reference: https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/

8. Software and Data Integrity Failures

Software and data integrity failures occur when code and infrastructure do not protect against integrity violations. Examples include relying on plugins, libraries, or modules from untrusted sources and having an insecure CI/CD pipeline that allows unauthorized access or malicious code. Auto-update functionalities without integrity verification pose risks, as attackers can distribute malicious updates. Additionally, insecure deserialization, where data structures are exposed and modifiable by attackers, can lead to vulnerabilities.

Understanding Integrity:

Software Integrity: Refers to the assurance that software functions as intended and has not been tampered with or maliciously modified.

Data Integrity: Ensures that data remains accurate and complete throughout its lifecycle, preventing unauthorized modifications or deletions.

Common Integrity Threats:

• Data Modification: Unauthorized changes to data, such as altering financial records, customer information, or sensitive data.
• Data Deletion: Accidental or intentional removal of critical data.
• Software Tampering: Malicious modification of software code to introduce vulnerabilities or backdoors.
• Supply Chain Attacks: Introducing malicious code into the software supply chain.
• Insecure Deserialization: Exploiting vulnerabilities in the deserialization process to execute arbitrary code.
• Insufficient Verification of Data Authenticity: Failing to verify the source and integrity of data before processing.

Prevention:

• Verify Software and Data Integrity: Employ digital signatures or similar methods to ensure that software or data originates from a trusted source and has not been tampered with.
• Check for Known Vulnerabilities: Implement software supply chain security tools, such as OWASP Dependency-Check or OWASP CycloneDX, to ensure that components do not contain known vulnerabilities.
• Review Code and Configuration Changes: Establish a review process for code and configuration changes to minimize the risk of introducing malicious code or insecure configurations into your software pipeline.
• Secure CI/CD Pipeline: Ensure proper segregation, configuration, and access control within your CI/CD pipeline to maintain the integrity of code throughout the build and deployment processes.
• Protect Serialized Data: Avoid sending unsigned or unencrypted serialized data to untrusted clients without integrity checks or digital signatures to prevent tampering or replay attacks.

Examples:

Scenario #1: Update without Signing: Many home routers, set-top boxes, and device firmware do not verify updates through signed firmware. Unsigned firmware presents a growing security risk and is increasingly targeted by attackers. This issue is critical because there is often no immediate remediation other than addressing it in future updates and waiting for older versions to be phased out.

Scenario #2: SolarWinds Malicious Update: Nation-states have targeted update mechanisms, as demonstrated by the SolarWinds Orion attack. Despite having secure build and update integrity processes, SolarWinds’ system was compromised. For several months, the company unknowingly distributed a highly targeted malicious update to over 18,000 organizations, affecting approximately 100. This incident represents one of the most extensive and significant breaches of its kind.

Reference: https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/

9. Security Logging and Monitoring Failures

Security logging and monitoring failures occur when systems or applications fail to adequately record or analyze security-relevant events, hindering the ability to detect, investigate, and respond to threats. This often results in delayed incident discovery, compromised incident response, and increased risk exposure.

Common Failures in Logging and Monitoring:

• Insufficient Logging: Failure to capture critical events, such as authentication failures, access attempts, or error messages, impedes comprehensive security monitoring.
• Poor Log Quality: Logs that are unclear, incomplete, or lack essential details can hinder effective analysis and incident response.
• Lack of Standardization: Inconsistent logging formats across different systems make it difficult to aggregate and analyze log data effectively.
• Log Retention Issues: Improper storage or deletion of logs can obstruct investigations and compromise the ability to perform thorough forensic analysis.
• Ineffective Alerting: The failure to generate timely and actionable alerts for critical events can delay incident response and remediation.
• Lack of Correlation: Inability to connect related events across different systems reduces the effectiveness of threat detection and response.
• Monitoring Blind Spots: Overlooking critical system components or network segments creates gaps in visibility and increases the risk of undetected threats.

Prevention:

• Comprehensive Logging: Ensure that all login attempts, access control failures, and server-side input validation errors are logged with sufficient user context to identify suspicious or malicious accounts. Logs should be retained for a period that allows for delayed forensic analysis.
• Compatible Log Formats: Generate logs in a format that can be easily ingested and processed by log management solutions.
• Audit Trail for High-Value Transactions: Implement audit trails for high-value transactions with integrity controls, such as append-only database tables, to prevent tampering or deletion.
• Effective Monitoring and Alerting: DevSecOps teams should establish robust monitoring and alerting mechanisms to quickly detect and respond to suspicious activities.
• Incident Response and Recovery Plan: Develop or adopt an incident response and recovery plan, such as the National Institute of Standards and Technology (NIST) 800-61r2 or later, to guide effective handling of security incidents.

Examples:

Scenario #1: A children’s health plan provider’s website suffered a breach that went undetected due to insufficient monitoring and logging. An external party alerted the provider that an attacker had accessed and altered thousands of sensitive health records for over 3.5 million children. A post-incident review revealed that significant vulnerabilities had been overlooked by the website developers. With no logging or monitoring in place, the breach could have been ongoing since 2013, spanning over seven years.

Scenario #2: A major Indian airline experienced a data breach involving more than a decade’s worth of personal data for millions of passengers, including passport and credit card information. The breach occurred at a third-party cloud hosting provider, which eventually notified the airline of the incident after a delay.

Reference:https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/

10. Server-Side Request Forgery 

Server-Side Request Forgery (SSRF) vulnerabilities occur when a web application retrieves a remote resource without validating the user-provided URL.This flaw allows attackers to manipulate the application into sending requests to unintended destinations, bypassing protections such as firewalls, VPNs, or network access control lists (ACLs).

As modern web applications increasingly offer features that involve fetching URLs, SSRF incidents are becoming more common. The severity of SSRF is also escalating due to the prevalence of cloud services and the growing complexity of application architectures.

SSRF Types:

1. Blind SSRF: In a blind SSRF attack, the attacker cannot view the response from the forged request but can infer information based on timeouts, error messages, or other indirect indicators.
2. Reflective SSRF: In a reflective SSRF attack, the attacker can observe the response from the forged request, which provides more detailed information about the target system.
3. Out-of-Band SSRF: In an out-of-band SSRF attack, the attacker can redirect the response to an external server they control, enabling them to collect data from the target system indirectly.

Prevention:

Network Layer:

• Isolate Remote Resource Access: Segment functionality for accessing remote resources into separate networks to limit the impact of SSRF attacks.
• Implement “Deny by Default” Policies: Apply firewall policies or network access control rules to block all traffic except for essential intranet communications.

Application Layer:

• Sanitize and Validate Input: Ensure that all data supplied by clients is thoroughly sanitized and validated.
• Enforce URL Constraints: Use a positive allow list to enforce acceptable URL schemas, ports, and destinations.
• Avoid Sending Raw Responses: Prevent information leakage by avoiding the transmission of raw responses from the application to clients.
• Disable HTTP Redirections: Prevent HTTP redirections to mitigate the risk of SSRF attacks.
• Monitor URL Consistency: Stay alert to URL consistency to guard against attacks like DNS rebinding and “time of check, time of use” (TOCTOU) race conditions.
• Avoid Deny Lists for Mitigation: Refrain from using deny lists or regular expressions for SSRF mitigation, as attackers can bypass these measures.

Additional Measures:

• Isolate Security Services: Avoid deploying security-relevant services on front-end systems (e.g., OpenID). Control local traffic on these systems (e.g., localhost).
• Use Network Encryption: For frontends with dedicated, manageable user groups, employ network encryption (e.g., VPNs) on separate systems to address high protection needs.

Examples:

Scenario #1: Port Scanning Internal Servers: In a network with no segmentation, attackers can map internal networks and determine open or closed ports on internal servers by analyzing connection results or the time taken to connect or reject SSRF payload connections.

Scenario #2: Sensitive Data Exposure: Attackers may exploit SSRF vulnerabilities to access local files or internal services, potentially exposing sensitive information such as file:///etc/passwd and http://localhost:28017/.

Scenario #3: Accessing Cloud Service Metadata Storage: Many cloud providers have metadata storage accessible at addresses like http://169.254.169.254/. Attackers can read this metadata to obtain sensitive information.

Reference: https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/

Final Words

Understanding the OWASP Top 10 vulnerabilities is crucial for developing secure web applications. By adopting the right security practices and staying updated on emerging threats, organizations can greatly mitigate their risk. Key measures include input validation, robust authentication, and secure coding practices to protect against common vulnerabilities such as SQL injection and cross-site scripting (XSS).

Application security is an ongoing process. Regular security assessments, detailed code reviews, and extensive employee training are essential for maintaining a strong security posture. Additionally, adopting a proactive approach to threat modeling and incorporating security into the software development lifecycle (SDLC) can further enhance an organization’s defenses against evolving cyber threats.

The post Understanding the OWASP Top 10 Application Vulnerabilities appeared first on Strobes Security.

*** This is a Security Bloggers Network syndicated blog from Strobes Security authored by Likhil Chekuri. Read the original post at: https://strobes.co/blog/understanding-the-owasp-top-10-application-vulnerabilities/