post-image

Insights to Inspire / Product Design & Development

Understanding the Top 10 Security Risks in Web Applications According to OWASP

author

Javier Ciceri

OWASP Top 10 is a document outlining the ten most critical security risks in web applications, according to the Open Web Application Security Project (OWASP) Foundation. Here is a brief summary of the 10 points, their common causes, and recommended actions to take. Common causes: Actions to take: Example: Changing roles by modifying HTML code. […]

Understanding the Top 10 Security Risks in Web Applications According to OWASP

OWASP Top 10 is a document outlining the ten most critical security risks in web applications, according to the Open Web Application Security Project (OWASP) Foundation.

Here is a brief summary of the 10 points, their common causes, and recommended actions to take.

  1. Access Control Failure: This occurs when a flaw or absence of access control mechanisms allows a user to access a resource beyond their intended permissions.

Common causes:

  • Bypassing access control checks by modifying the URL.
  • Allowing viewing or editing of another person’s account with just their unique identifier.
  • Manipulating metadata, such as reusing or modifying a JSON Web Token (JWT) access control token.
  • Incorrect CORS configurations.

Actions to take:

  • Deny access by default, except for public resources.
  • Log access control failures (login) and alert administrators when appropriate.
  • Invalidate session identifiers on the server after logging out.

Example: Changing roles by modifying HTML code.

  1. Cryptographic Failures: This vulnerability is related to applications published over plaintext services (HTTP). However, even applications that implement encrypted communication (HTTPS) can be vulnerable if encryption algorithms are not implemented correctly or are weak and can be compromised.

Common causes:

  • Transmitting data in plaintext over non-encrypted protocols (HTTP, SMTP, FTP).
  • Using outdated or weak cryptographic algorithms or protocols by default or in old code.
  • Using passwords as cryptographic keys.

Actions to take:

  • Classify processed, stored, or transmitted data by the application and identify which data is confidential.
  • Avoid storing sensitive data unnecessarily.
  • Use the most up-to-date SSL/TLS Protocol versions with well-known and non-vulnerable ciphers, and certificates based on well-known and strong encryption algorithms.
  • Ensure encryption of all sensitive data at rest (storage).
  • Protect the data while it is in use with IAM tools like multi-factor authentication, role-based access model permissions, and digital rights protection or IRM. 
  • Disable caching for responses containing sensitive data.

Example: Capturing data by inspecting insecure information transmitted over the network.

  1. Code Injection: Injection flaws, such as SQL, XSS, OS, and LDAP injections, occur when untrusted data is sent to an interpreter as part of a command or query. Hostile attacker data can trick the interpreter into executing unintended commands or accessing unauthorized data.

Common causes:

  • User-provided data is not validated, filtered, or sanitized by the application.
  • Malicious data is used within search parameters in Object-Relational Mapping (ORM) queries to extract additional sensitive records.
  • Malicious data is used directly or concatenated, resulting in SQL or command injection with dynamic queries, commands, or stored procedures.

Actions to take:

  • Prefer using a secure API that avoids using an interpreter altogether and provides a parameterized interface or using an ORM tool.
  • Implement input data validation on the server.
  • For any remaining dynamic queries, escape special characters using interpreter-specific character syntax.
  • Use LIMIT and other SQL controls within queries to prevent mass record leakage in case of SQL injection.

Example: Modifying input data to generate a SQL code injection and gain access to private information.

  1. Insecure Design: When designing applications, developers are recommended to use secure design patterns, carefully planned threat models, and reference architectures to keep the application free from security incidents. 

Actions to take: 

● Establish and use a secure development lifecycle supported by Application Security Professionals to help assess and design security and privacy-related controls. 

● Establish and use a catalog of secure design patterns or “paved road” components ready to be used. 

● Integrate security language and controls into user stories. 

● Limit resource consumption per user or service.

  1. Insecure Security Configuration: This occurs when application components are insecurely or incorrectly configured and usually do not follow best practices. It can occur at any level of applications, including network services, web servers, application servers, and databases. Incorrect security configuration failures can include unnecessary features (e.g., unnecessary ports, accounts, or privileges), default accounts and passwords, and error handling that reveals too much information about the application. 

Common causes: 

● Unnecessary features 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. 

● Software is outdated or vulnerable. 

Actions to take: 

● Minimize the platform to include only necessary features, components, documentation, and examples. Remove or do not install unused features and frameworks. 

● Have a task to review and update appropriate configurations for all security notes, updates, and patches as part of the patch management process. 

● Send security policies to clients, e.g., security headers. 

● Establish an automated process to verify the effectiveness of configurations and settings in all environments. 

Example: Allowing access to a method of a service without requiring authentication.

  1. Vulnerable and Outdated Components: These occur when a software component is unsupported, outdated, or vulnerable to a known exploit. Development with many components can lead to development teams not knowing or understanding which components they use in their applications. 

Common causes: 

● Lack of knowledge about the versions of all components being used. 

● Software is vulnerable, unsupported, or not up-to-date. 

● Failure to regularly scan for vulnerabilities and subscribe to security bulletins related to the components being used. 

● Failure to timely repair or update the underlying platform, frameworks, and dependencies based on risk. 

Actions to take: 

● Eliminate unused dependencies, functionalities, components, files, and unnecessary documentation. 

● Maintain a continuous inventory of component versions on the client and server (e.g., frameworks, libraries) and their dependencies using tools like OWASP Dependency Check, retire.js, etc. 

● Obtain components only from official sources through secure links. 

● Monitor libraries and components that are no longer maintained or do not provide security patches for older versions. 

Example: Outdated packages in an application.

  1. Identification and Authentication Failures: Functions related to authentication and session management, when implemented incorrectly, allow attackers to compromise passwords, keywords, and sessions, which can lead to user identity theft and more. 

Common causes: 

● Allowing automated attacks such as the reuse of known credentials, where the attacker possesses a list of valid username and password pairs. 

● Allowing brute-force attacks or other automated attacks. 

● Allowing default, weak, or well-known passwords such as “Password1” or “admin/admin.” 

● Storing passwords in plain text, weakly encrypted, or using weak hashing functions. 

● Lacking multi-factor authentication or having an ineffective implementation. 

Actions to take: 

● When possible, implement multi-factor authentication to prevent automated attacks like the reuse of known credentials, brute force, and the reuse of stolen credentials. 

● Do not include or implement default credentials in your software, particularly for administrative users. 

● Ensure that registration, credential recovery, and API usage do not allow user enumeration attacks by using the same generic messages in all outputs.

Example: By obtaining a credential, an attempt is made to access different sites or services with the same credentials.

  1. Software and Data Integrity Failures: Software and data integrity failures are related to unprotected code and infrastructure against alterations

Common causes: 

● For example, when an application relies on plugins, libraries, or modules from untrusted sources, repositories, or content delivery networks (CDNs). 

● An insecure CI/CD pipeline can lead to unauthorized access, the inclusion of malicious code, or compromising the system in general. 

● It is common nowadays for applications to implement update functionalities through which new versions of the application are downloaded without proper integrity checks performed before installation. 

Actions to take: 

● Use digital signatures or similar mechanisms to verify that the software or data indeed comes from the expected source and has not been altered. 

● Ensure that libraries and dependencies, such as npm or Maven, are used from trusted repositories. If your risk profile is high, consider hosting them in an internal repository whose contents have been previously analyzed. 

● Ensure that a code and configuration change review process is used to minimize the chances of malicious code or configurations being introduced into your pipeline. 

● Ensure that your CI/CD pipeline has adequate access controls, segregation, and configurations that ensure code integrity throughout the build and deployment process.

Example: Injecting code into unverified components that are used by applications enables the attacker to have control over our environment.

  1. Registration and Monitoring Failures: Registration and monitoring are activities that should be regularly performed on a website; failure to do so leaves the site vulnerable to more serious and compromising activities. 

Common causes: 

● Auditable events, such as logins, login failures, and high-traffic data transactions, are not logged. 

● Warnings and errors generate unclear or inadequate logs, and in some cases, no logs are generated at all. 

● Applications fail to detect, escalate, or alert about real-time or near-real-time active attacks. 

Actions to take: 

● Ensure that all server-side login errors, access control failures, and input validation errors can be logged with sufficient context to identify suspicious or malicious accounts and retain them long enough for subsequent forensic analysis. 

● Ensure that logs are generated in a format that is easy to process by log management tools. 

● DevSecOps teams should establish effective alerts and monitoring to detect suspicious activities and respond promptly.

Example: Failure to monitor or lack of access failure logs prevents us from being prepared and taking action before security issues arise.

  1. Server-Side Request Forgery (SSRF): SSRF vulnerabilities occur when a web application retrieves a remote resource without validating the URL provided by the user. It allows an attacker to coerce the application into sending a forged request to an unexpected destination. 

Common causes: 

● Lack of validation for the source URLs. 

Actions to take: 

● Sanitize and validate all input data provided by the client. 

● Enforce the URL scheme, port, and destination through a positive list of allowed items. 

● Do not send “raw” responses to clients. 

● Disable HTTP redirects. 

● Consider URL consistency to prevent attacks such as DNS rebinding and time-of-check to time-of-use (TOCTOU) race conditions. 

Example: Failing to validate request origins exposes our services to being accessed from unexpected or insecure locations.

To sum up, OWASP Top Ten 2021 is an essential tool for anybody who wants to protect their systems and online information. Analyzing the vulnerabilities in this list helps us gain awareness of how exposed we are to the most common attacks. It’s a difficult task that requires time, even more so if we don’t have a security department to work with. Ideally, we should have this list in mind when we start a project and implement it as it grows.