- 3 min read

Builder.addons.mozilla.org Security Flaw: Anti-CSRF Token Bypass Uncovered

Updated: Dec 2, 2023

Introduction

As an enthusiastic security researcher participating in Mozilla's bug bounty program, I came across an intriguing CSRF (Cross-Site Request Forgery) vulnerability on the Builder.addons.mozilla.org platform. CSRF vulnerabilities are a significant concern in web security, and this discovery exposed a potential threat to the integrity of the platform. In this blog post, I will share the details of this vulnerability and how it was responsibly disclosed and addressed.

Understanding CSRF Vulnerabilities

Before delving into the specifics of the vulnerability, let's briefly explain what CSRF vulnerabilities are. CSRF is a type of web security vulnerability that enables an attacker to trick a user into performing actions on a web application without their knowledge or consent. These actions can range from altering user settings to making unauthorized changes to an account.

The Discovery

While exploring the Builder.addons.mozilla.org platform, I stumbled upon a CSRF vulnerability that allowed me to bypass the Anti-CSRF token validation. This validation was already taking place on the server-side, making it challenging to execute a CSRF attack. Nonetheless, I was determined to find a way to exploit this vulnerability.

Challenges Faced

I encountered several challenges along the way. The Anti-CSRF Token was initially being validated on the server-side, which is typically a strong defense against CSRF attacks. I attempted various known techniques, including token re-use, pattern analysis, complexity checks, length-based validation and more. None of these strategies proved successful.

In Search of a Solution

With my back against the wall, I explored three potential avenues to bypass the token validation. The first option involved predicting or guessing the token, which proved fruitless. The second option was to find weaknesses in the token validation itself, but this endeavor was equally unsuccessful. The third and final option was to identify a method by which the CSRF token validation could be circumvented.

The Breakthrough

Inspiration struck when I considered changing the default POST request method to GET. By doing this, I could remove the CSRF token parameter and value from the request, along with the XMLHttpRequest request type header. These changes would allow me to craft a GET request that bypassed server-side Anti-CSRF token validation. I meticulously created a CSRF payload with a modified GET request, and it worked! This crafted request could execute actions on the victim's account without Anti-CSRF token validation.

Actual Form Submission Request with Original Anti-CSRF Token Parameter Value and Request Type Header:

POST /package/delete/157917/ HTTP/1.1
Host: builder.addons.mozilla.orgCookie: JSESSIONID=SessionValue; Domain=builder.addons.mozilla.org; Secure; HttpOnlyContent-Type: application/x-www-form-urlencodedRequest-Type: XMLHttpRequestCSRFToken=9H217mdn3h12h1n1j1j1j1j1

Add-on Deletion & Anti CSRF Token Bypass(Modified GET Request after changing the default Method and after Removing the CSRF Token and XMLHttpRequest request type Header:

<html>  
<body>    
<form action="https://builder.addons.mozilla.org/package/delete/157917/" method="GET">      
<input type="submit" value="Submit form" />    
</form>  
</body>
</html>

Exploiting the Vulnerability

The attack involved crafting a malicious payload that was shared with the victim as a link. When the victim unwittingly executed the payload while logged into their account, the consequences were severe. Their add-ons were deleted, private add-ons were made public, and unpublished add-ons were published, all without their consent.

Recommendations

To mitigate this vulnerability and prevent future CSRF attacks, I recommend implementing the following security measures:

Anti-CSRF token validation should not be solely based on the Request Method and Request Type.
Request Type headers (e.g., XMLHttpRequest) should be enforced, and normal requests should not be allowed.
CSRF tokens should be one-time-use and should not be reusable.
CSRF tokens should be rigorously validated on the server-side.
CSRF tokens should expire after use and be generated randomly for each request.
Consider using the PUT method instead of POST for enhanced security.

Response and Resolution

Upon reporting this vulnerability to Mozilla's Security Team, they swiftly addressed the issue and implemented measures to enhance the security of their platform.

Conclusion

This CSRF vulnerability discovery underscores the importance of diligent security research and responsible disclosure. By sharing this experience, I hope to raise awareness about the potential risks associated with CSRF vulnerabilities and encourage platform owners to continually improve their security measures. CSRF vulnerabilities pose a serious threat to user data and platform integrity, and it is crucial that they are promptly addressed to protect both users and the organizations that rely on their services.