Introduction
The OWASP-Top-10 is a list of the top 10 web application security risks, as compiled by the Open Web Application Security Project (OWASP), a non-profit organization dedicated to improving the security of software. OWASP provides resources, tools, and guidance to developers, security professionals, and organizations to help them create more secure software and make it more accessible to developers and organizations of all sizes.
The OWASP-Top-10 list itself serves as a guide for organizations to prioritize their security efforts and ensure that they are addressing the most critical vulnerabilities in their web applications that are most likely to be exploited by attackers and that could have the most severe impact on their business. The list is especially important because it provides a common language and framework for developers and organizations, as well as security experts when discussing potential security risks in their web applications. This guidance is based on best practices and is continually updated as new techniques and technologies emerge. The list is updated every few years to reflect changes in the threat landscape, ensuring that it remains relevant and up-to-date.
In this article, we will present open-appsec capabilities while addressing each of the OWASP-top-10 risks.
open-appsec
open-appsec is an open-source Web Application & API Security solution. Its code is available on GitHub. open-appsec provides automatic security using machine learning. It has proven multiple times to effectively protect against zero-day and OWASP-Top-10 attacks, as it is not signature-dependent but uses contextual machine learning instead. open-appsec reduces the administrative effort as well as the amount of false positives significantly while providing strong protection even for yet-unknown, zero-day attacks. open-appsec supports all typical deployment platforms like VMs, Kubernetes, and Docker and integrates with NGINX, NGINX Ingress, and Kong. More integrations will be added soon.
As signatures for new attacks, by design, can only be created after new attacks have been published, a WAF solution that relies solely on signatures will not protect preemptively (in advance) against zero-day attacks. This is especially important as a vulnerability usually exists for a long time within an affected code of a software or a library, before the first public disclosure of a corresponding CVE record describing it.
The following timeline visualizes the three relevant phases related to the ‘Vulnerability Window’:
open-appsec's Machine Learning-based approach can solve this challenge and provide true preemptive protection against zero-day attacks while functioning independently of any signature updates and keeping false positives to a minimum level.
open-appsec’s automatic machine learning engine continuously analyzes HTTP/S requests to Websites or APIs. Incoming HTTP/S requests are evaluated against two machine-learning models:
a supervised model that was trained offline with millions of malicious and benign requests.
a non-supervised model that is built in real-time in the protected environment and is specific to its traffic patterns.
Contextual analysis includes the application’s structure and how users interact with its content, in order to automatically stop and block malicious requests and bad actors.
In parallel to the ML engine, open-appsec provides additional security capabilities. To name a few, IPS engine with Snort support, behavioral AntiBot protection (in Premium edition), and a huge collection of cloud IOCs for blocking malicious IPs, Anonymizers, and Tor (in Enterprise edition).
OWASP-Top 10 risks and open-appsec capabilities to prevent them
1. Broken Access Control – This risk includes flaws such as insufficient authorization checks, misconfigured permissions, and failure to enforce user roles and privileges, which can allow attackers to access resources or perform actions they should not be able to. Failure as such can typically lead to unauthorized information disclosure, modification, or destruction of all data or to performing a business function outside the user's limits.
open-appsec can help to address this risk:
open-appsec’s ML engine continuously analyzes HTTP/S requests to websites or APIs and therefore can detect or prevent parameter tampering, API request modifications and much more as this will deviate from the typical learned behavior of the web application’s HTTP requests.
open-appsec’s ML engine will detect or prevent privilege elevation attacks based on threat indicator analysis and contextual analysis.
open-appsec’s ML will detect or prevent forced browsing based on predictable resource location access, file enumeration, directory enumeration, and resource enumeration, as this access would deviate from the learned baseline and impact the request’s scoring.
open-appsec’s AntiBot module will prevent attacks on broken access control originating from automated bots instead of humans, by validating JavaScript availability, mouse movements, and much more on the client side.
open-appsec’s ML engine will prevent CSRF (Cross-Site Request Forgery) attacks using its special CSRF protection feature.
open-appsec’s ML engine will prevent Path Traversal attacks based on its indicator analysis as part of the full contextual ML analysis.
open-appsec’s ML engine detects or prevents users from performing activities (known and unknown attacks) that are considered as a risk to a web environment, based on an offline, supervised ML model which was trained with millions of malicious and benign requests and an online model which continuously analyses and baselines the web application & API traffic reaching the protected applications, considering multiple and separate contexts like user behavior, URL, individual header parameters, and more. This detection is not depending on signatures at all.
open-appsec’s IPS module provides additional signatures preventing various privilege elevation attacks and path traversal attacks.
open-appsec allows configuring custom rules based on regular expressions, detected in key locations in HTTP/S traffic. The custom rules can allow creating signatures to be excluded from detection, but also add specific signatures that will always be dropped. The ability to configure such signatures to be detected on the HTTP/S Response body provides means of configuring Data Loss Prevention (DLP) signatures that will be dropped.
2. Cryptographic Failures – This risk relates to failures in cryptography or the lack of it, which can often lead to exposure of sensitive data. An example of such an attack according to the OWASP website, can be a scenario where an application encrypts credit card numbers in a database using automatic database encryption. However, this data is automatically decrypted when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text. Another example is when a site doesn't use or enforce TLS for all pages or supports weak encryption. A potential attacker can monitor the network traffic (e.g., at an insecure wireless network), downgrade the connections from HTTPS to HTTP, intercept requests, and steal the user's session cookie. The attacker can then replay this cookie and hijack the user's (authenticated) session, access or modify the user's private data, or even alter all transported data, e.g., the recipient of a money transfer.
open-appsec can help to address this risk:
SSL encryption can be flexibly configured in open-appsec and its underlying proxy can enforce TLS 1.2 encryption.
Forward secrecy ciphers and HSTS can also be enforced by the underlying NGINX.
open-appsec’s ML engine detects or prevents typical attacks leading to data breaches such as SQL injection, OS command injection, thus reducing risk for attackers accessing encrypted data strongly. This detection is not depending on signatures at all.
We can enforce allowing incoming SSL traffic only.
open-appsec’s IPS module provides additional signatures preventing attacks leading typically to data breaches.
open-appsec’s AntiBot feature prevents bots from exploiting existing misconfiguration in the protected environments.
open-appsec allows configuring custom rules based on regular expressions, detected in key locations in HTTP/S traffic. The custom rules can allow creating signatures to be excluded from detection, but also add specific signatures that will always be dropped. The ability to configure such signatures to be detected on the HTTP/S Response body provides means of configuring Data Loss Prevention (DLP) signatures that will be dropped.
3. Injection - Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query, leading to unintended actions or data disclosure. According to the OWASP website, this can happen 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.
open-appsec can help addressing this risk:
open-appsec’s Machine Learning (ML) engine detects/prevents various injection attacks, including zero-days, using the offline supervised ML model and in addition strongly reduces false positives based on multi-vector contextual analysis using the second online, supervised ML model. This detection is not depending on signatures at all.
Among the prevented injection attacks are e.g. SQL injection, command injection, XSS, LDAP injection, static code injection, PHP remote file inclusion, and more.
In comparison to other existing WAF solutions, open-appsec’s ML engine is not only used for reducing False Positives (FPs) but it is used as the primary engine for the actual detection/prevention of attacks (as well as FP reduction). This enables unique preemptive detection/prevention capabilities.
4. Insecure Design - Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design”. OWASP emphasizes that 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.
open-appsec can help to adress this risk:
open-appsec’s ML engine can detect/prevent external control of file name or path based on the behavioral baselining.
open-appsec’s ML engine can detect/prevent uncommon inputs deviating from normal usage.
open-appsec’s ML engine will detect known and unknown payloads attempting to trigger error messages to show sensitive information based on attack indicator detection and contextual analysis to eliminate false positives.
open-appsec’s error disclosure protection can prevent technical information disclosure to attackers in server error messages.
open-appsec’s parsers will always scan the full request independent of Transfer-Encoding or Content-Length headers to prevent malicious payloads in smuggled HTTP requests.
5. Security Misconfiguration - This vulnerability includes flaws such as leaving default passwords or other settings in place, misconfigured security settings, and missing patches or updates, which can leave applications vulnerable to attack. The application might be vulnerable if it 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).
open-appsec can help to address this risk:
open-appsec’s ML engine can detect/prevent attempts to misuse access by recognizing deviations from regular usage. If there’s a misconfiguration within the environment and an attacker tries to gain access, this would be a deviation from normal usage.
open-appsec’s ML engine prevents exploitation of known and unknown vulnerabilities caused by security misconfiguration without any signatures.
open-appsec’s IPS layer provides additional protection against exploitation of misconfiguration in many common web applications like (e.g. WordPress, Joomla, Drupal, …) based on signatures.
6. Vulnerable and Outdated Components - Usage of vulnerable and outdated components is very common and poses a huge risk to all types of web applications. 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).
open-appsec can help to address this risk:
open-appsec’s ML engine’s preemptive protection capabilities are highly effective to protect exploitation of known and unknown vulnerabilities in current and outdated components (proven recently against e.g. the Log4shell, Spring4shell, and Text4shell attacks).
open-appsec provides real 0-day protection without relying on signatures or requiring any signature update while minimizing false positives effectively using the contextual ML engine.
open-appsec’s ML engine covers many attack categories like Injections, XSS, CSRF, Path Traversal, Command Execution, XXE and more including new attacks types.
open-appsec’s IPS layer provides additional virtual patching for many common web applications like (e.g. WordPress, Joomla, Drupal, …) protecting against known vulnerabilities based on signatures.
File security.
In addition, the open-appsec team follows newly disclosed vulnerabilities and continuously verifies the efficiency of Open-appsec’s ML engine’s supervised offline model, which is frequently improved/trained with “fresh” malicious and benign HTTP requests to further improve it.
We have our own, strong research team investigating this.
open-appsec supports the commonly-used, open-source SNORT signature format to create and add custom signatures to be prevented in case required. Often SNORT signatures are shared among information security experts to describe common attributes of known, observed malware.
7. Identification and Authentication Failures - This includes flaws such as failing to use SSL/TLS encryption or using it improperly, which can allow attackers to intercept and steal sensitive data transmitted over the network. 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.
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.
open-appsec can help to address this risk:
open-appsec’s ML engine tracks and continuously analyzes session variables, without impacting the session management of the protected application.
open-appsec’s AntiBot engine prevents automated attack attempts by validating e.g. human behavior and Java script existence on the client side.
open-appsec’s underlying web proxy (e.g. NGINX) can validate SSL certificates.
8. Software and Data Integrity Failures - Software and data integrity failures relate to code and infrastructure that do 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.
open-appsec can help to address this risk:
open-appsec’s ML can detect attempts to access untrusted search paths based on attack indicator analysis in combination with other contexts e.g. the user reputation.
open-appsec’s AntiBot engine prevents automated attack attempts trying to exploit software and data integrity failures by validating e.g. human behavior and Java script existence on the client side.
open-appsec’s File security feature (available in open-appsec Enterprise edition/CloudGuard Appsec) can check files for known malware and the integrated Threat Emulation functionality can also emulate files to find and prevent unknown malware thus adding true zero-day prevention for files as well.
9. Security Logging and Monitoring Failures - Without logging and monitoring, breaches cannot be detected. Insufficient logging, detection, monitoring, and active response occurs at any time:
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.
The application cannot detect, escalate, or alert for active attacks in real-time or near real-time.
open-appsec can help to address this risk:
open-appsec itself provides rich and flexible logging options (local, central (SaaS mgmt), and external logs are supported) and integrates nicely with many external solutions (syslog, CEF, …)
open-appsec Logging can be configured granularly.
open-appsec provides in-depth monitoring capabilities.
open-appsec provides graphical reporting and event analysis capabilities.
open-appsec can be integrated also with other solutions like Prometheus/Grafana for monitoring or ELK for security events analytics (soon).
10. Server-Side Request Forgery - 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.
open-appsec can help to address this risk:
open-appsec’s Threat Cloud integration provides a DNS reputation that can be used for detecting/preventing any communication involving malicious DNS names (soon).
open-appsec’s ML engine identifies anomalies in payloads (which in this case could be IP addresses or domains in the requests).
open-appsec’s ML engine can detect/prevent SSRF based on attack indicator analysis.
In the context of K8s clusters, it is planned to add also K8s Micro-Segmentation functionality which will further assist in preventing successful SSRF attacks by implementing Zero Trust access control enforcement on the microservice level (soon).
To learn more about open-appsec’s ML, download the White Paper Preemptive Web Application Protection using Contextual Machine Learning.
You can also experiment hands-on with deploying open-appsec in live Playgrounds here.
Video Tutorials for open-appsec’s deployment options are available here.
