Exploiting JSON-Based CSRF: The Hidden Threat in Profile Management
PreviousDecoding Server Behavior: The Key to Mass Account TakeoverNextHow We Turned a Medium XSS into a High Bounty by Bypassing HttpOnly Cookie
Last updated
Was this helpful?
Last updated
Was this helpful?
During my work with @ In a recent penetration testing engagement with a technology company that focuses on AI-driven accessibility solutions,.
Target is a technology company working to solve challenges of web accessibility through AI. The company has raised $58 million in two rounds of funding
I encountered an interesting CSRF (Cross-Site Request Forgery) vulnerability. The flaw allowed unauthorized changes to sensitive profile settings, including Personally Identifiable Information (PII). The vulnerability was particularly unique due to its exploitation method, leveraging JSON-structured requests and bypassing the content type restrictions.
This write-up dives into the technical challenges, the critical importance of securing PII, and how an often-overlooked CSRF vulnerability in JSON requests can lead to severe consequences.
CSRF vulnerabilities occur when an attacker tricks an authenticated user into performing unintended actions on a vulnerable web application without their knowledge. These attacks typically exploit the lack of proper request validation and take advantage of a user’s session with the target system.
In a standard CSRF scenario, the browser automatically includes session cookies and headers with any requests sent to a web application. This means that if the user is logged into their account and unknowingly clicks a malicious link, the attacker can perform unauthorized actions like changing user information, deleting resources, or performing sensitive actions — all without the victim realizing it.
While traditional CSRF attacks often involve form submissions, the vulnerability I found during this engagement took on a different form: JSON-based CSRF.
Modern applications often rely on JSON (JavaScript Object Notation) to transmit structured data between client and server. While JSON-based requests add flexibility to APIs and modern web services, they can introduce unique security challenges, especially when CSRF protection is overlooked.
The application in question lacked a mechanism to validate JSON requests for CSRF tokens when users modified their profile information. What made this case particularly tricky was the server’s handling of the Content-Type header. Instead of the typical application/json, the server accepted requests with the Content-Type set to text/plain, which allowed an attacker to send JSON-structured data through a crafted request.
Upon attempting to modify the profile information, I intercepted the outgoing request to investigate its structure and behavior. Here's what the request looked like:
Request Payload:
Since there is no CSRF-Token. The first thing I did was dive into the cookie flags using browser developer tools. I found various cookies were set, but the most interesting one was the session cookie, which had the HttpOnly and Secure flags properly set. This meant the cookie couldn't be easily accessed via JavaScript, and it was only transmitted over secure HTTPS connections. However, the SameSite flag was set to None, a red flag in itself since it could allow cross-site requests depending on how other security measures were implemented.
To test how dependent the request was on these cookies, I sent the request with only the session cookie parameter. Surprisingly, the request was successfully processed, suggesting that the session cookie alone was all that was needed for authentication—there were no additional checks involving headers like Referer or Origin.
At this point, I noticed that the Content-Type of the request was set to application/json. Typically, JSON-based requests are less susceptible to CSRF because of the same-origin policy in most browsers. However, I saw a possible weakness in the Accept: */* header, which indicated that the server accepted all types of content formats, not just JSON.
This was where I saw an opportunity: I decided to test if the server would accept requests with a Content-Type of text/plain. If successful, this would open the door to a CSRF vulnerability since plain-text form submissions could be exploited in cross-site request forgery attacks.
text/plain HypothesisI modified the Content-Type header in the intercepted request to text/plain and sent it again. To my surprise, the server accepted the request and processed it successfully, even though it was supposed to handle JSON.
This confirmed the presence of a potential CSRF vulnerability. Now, the next step was to create a Proof of Concept (PoC) using Burp Suite's CSRF PoC generator, but I hit a snag here.
The CSRF PoC generated by Burp looked like this:
However, the request generated by this PoC was formatted incorrectly. The = symbol at the end of the JSON payload caused the server to misinterpret the request as a malformed JSON:
The presence of the = symbol at the end was unexpected, and the server returned a parsing error:
so i tried the known bypass to add another parameter with anything in the value and will treat = as normal string but sadly this didn't work
this resulted in error
To bypass this issue, I realized the = symbol could be "hidden" within a known parameter value instead of being treated as part of a new parameter. I tweaked the PoC code as follows:
Unfortunately, the server still rejected the request, returning this error:
This confirmed that the server strictly validated the country field against a set of predefined values and did not accept arbitrary characters like =.
We’re not at the finish line yet, but here’s where things get interesting. After realizing that the issue with = being treated as part of the JSON structure was causing issues, I decided to embed the payload in the name parameter, where the server would treat it as normal text in the user’s name. This subtle approach led to a successful CSRF attack.
The CSRF PoC looked like this:
This PoC sends a request like this:
As you can see, this worked flawlessly. The account settings could be updated with arbitrary values, effectively allowing an attacker to alter user profile details.
However, I attempted to escalate the issue into an account takeover (ATO) by adding the email parameter to the request. Despite my efforts, it turned out that the platform doesn’t allow users to change their email address, mitigating the risk of full ATO. Nevertheless, the vulnerability still posed a significant risk, as any data in the user's account settings (except the email) could be manipulated.
It all started when I logged in to the targeted dashboard at . I was particularly interested in testing the security of PII (personally identifiable information) data in the profile section, knowing how crucial it is for both users and companies to safeguard such information. Immediately, I navigated to to check for vulnerabilities in the account information update functionality.
