Programming
What does a Ajax call response like for json data mean duplicate
Navigating the intricate world of web development often brings developers face-to-face with seemingly cryptic code snippets. One such mystery that frequently puzzles those working with asynchronous JavaScript and XML (Ajax) calls is a response formatted like for (;;); { json data }. This peculiar prefix, an infinite loop followed by curly braces enclosing your expected JSON data, isn’t a bug or a malformed response. Instead, it’s a deliberate and crucial security measure designed to protect your application from specific types of attacks. Understanding what this Ajax call response means is essential for building robust and secure web applications, particularly when dealing with sensitive user data and preventing vulnerabilities like JSON hijacking.
Understanding the for (;;); Prefix in Ajax Responses
The unusual for (;;); prefix preceding JSON data in an Ajax response might look like an error at first glance, but it serves a vital security function. This seemingly infinite JavaScript loop, when directly executed by a browser, would cause the script to hang indefinitely. Its primary purpose is to prevent an attacker from directly evaluating sensitive JSON data if it were loaded as a script on a malicious page. Essentially, it’s a defensive programming technique to protect against an old, but still relevant, security vulnerability known as JSON hijacking.
In the early days of web development, browsers allowed script tags to load resources from different origins, including JSON data. If a malicious website could trick a user’s browser into loading a sensitive JSON endpoint (e.g., one containing personal user data) using a <script> tag, the data could potentially be accessed and leaked. The for (;;); prefix makes such direct execution impossible. When the browser attempts to parse this, it enters an endless loop, preventing any subsequent JSON object from being assigned to a variable or accessed through global scope. This simple yet effective measure ensures that only an XMLHttpRequest (or Fetch API request) from an authorized domain, which explicitly expects and processes this format, can successfully retrieve and parse the intended JSON data.
The Threat: JSON Hijacking and CSRF
The for (;;); prefix directly addresses the threat of JSON hijacking, a specific type of Cross-Site Request Forgery (CSRF) attack. In a JSON hijacking scenario, an attacker attempts to steal sensitive data that a legitimate user might be able to access from a trusted website. This vulnerability arises when a web application serves JSON data without proper cross-origin protections, making it susceptible to being loaded and potentially exploited by a third-party website.
Historically, browsers would allow a <script> tag to load JSON responses from other domains. If an endpoint returned an array or object directly (e.g., [{...}] or {...}), a malicious script could potentially redefine array or object constructors or prototypes, then load the victim’s sensitive JSON endpoint via a script tag. This could allow the attacker to intercept and exfiltrate the data. For instance, if an API endpoint returned a user’s private messages as a JSON array, an attacker’s page could include <script src="https://example.com/api/messages"></script>. Without the prefix, the browser would execute this as a script, potentially allowing the attacker to read the messages. According to OWASP, “The term ‘JSON Hijacking’ refers to a class of vulnerabilities that allow an attacker to read sensitive JSON data from a cross-domain request.” This highlights the critical need for server-side defenses.
While modern browsers have implemented stronger same-origin policies and Content Security Policies (CSP) to mitigate some of these risks, the for (;;); prefix remains a robust, defense-in-depth mechanism. It acts as an additional layer of protection, ensuring that even if other security layers were bypassed or misconfigured, the raw JSON data cannot be directly executed as JavaScript by an unauthorized party. This makes it an effective countermeasure against data leakage through script inclusion attacks, reinforcing the security posture of applications handling sensitive information.
Implementing the for (;;); prefix is a server-side responsibility, typically handled by the application framework or custom logic. When a server receives an XMLHttpRequest for JSON data, it determines whether to apply this security measure. This decision often depends on the specific API endpoint and the nature of the data being requested. For endpoints that return sensitive user-specific information, the server will prepend the for (;;); string to the JSON payload before sending the response back to the client.
The server’s logic usually involves checking the request method, headers (like X-Requested-With which often indicates an Ajax request), and the authenticated user’s session. Upon confirming it’s an API request from a trusted source for sensitive data, the server constructs the response by concatenating the prefix string with the serialized JSON. For example, a server might take a JSON object like {"user": "Alice", "balance": 1000} and transform it into for (;;); {"user": "Alice", "balance": 1000}. This ensures that only the intended client-side script, which knows how to strip this prefix, can successfully parse the data. Without this server-side addition, the raw JSON would be exposed, potentially leading to security vulnerabilities. This server-side precaution is a fundamental aspect of securing sensitive data transmitted via Ajax calls.
Client-Side Handling of the Prefixed Response
Once the Question & Answer :
I found this kind of syntax being used on Facebook for Ajax calls. I’m confused on the for (;;); part in the beginning of response. What is it used for?
This is the call and response:
GET http://0.131.channel.facebook.com/x/1476579705/51033089/false/p_1524926084=0
Response:
for (;;);{"t":"continue"}
I suspect the primary reason it’s there is control. It forces you to retrieve the data via Ajax, not via JSON-P or similar (which uses script tags, and so would fail because that for loop is infinite), and thus ensures that the Same Origin Policy kicks in. This lets them control what documents can issue calls to the API — specifically, only documents that have the same origin as that API call, or ones that Facebook specifically grants access to via CORS (on browsers that support CORS). So you have to request the data via a mechanism where the browser will enforce the SOP, and you have to know about that preface and remove it before deserializing the data.
So yeah, it’s about controlling (useful) access to that data.
