JSON hijacking refers to attackers executing malicious scripts in the user's browser to steal sensitive data returned in JSON format.
Such attacks typically target web applications that retrieve JSON data using GET requests, as early browsers allowed the src attribute of the <script> tag to fetch cross-origin resources, meaning JSON data obtained via GET requests could be inadvertently included in third-party pages.
The reason why using the POST method prevents JSON hijacking is that POST requests are not executed by the browser's <script> tag, reducing the likelihood of data being hijacked.
When using POST requests, browsers do not automatically execute the returned data as scripts, thereby preventing simple hijacking via the <script> tag.
Moreover, adhering to the same-origin policy, cross-origin POST requests cannot be initiated via XMLHttpRequest to retrieve data unless explicitly allowed by the server.
Additionally, POST requests are typically used for handling requests that may alter server state, so browsers and servers often implement additional security measures, such as CSRF tokens (Cross-Site Request Forgery tokens), to verify the legitimacy of the request source. This provides an extra security layer against JSON hijacking.
Example:
Imagine a web application that retrieves user information using the following URL:
http://example.com/getUserInfo?userId=12345
Attackers can create a <script> tag on their controlled website with the src attribute set to the above URL. If the user visits the attacker's site while logged into example.com and example.com lacks appropriate cross-origin policies, the attacker may obtain user information.
If the web application uses POST requests instead:
POST http://example.com/getUserInfo Body: { "userId": "12345" }
In this case, even if attackers attempt to initiate POST requests via the <script> tag, it will fail because the <script> tag does not support POST methods. Attackers also cannot use XMLHttpRequest to initiate cross-origin requests to read data unless the server explicitly allows it.
Therefore, using POST requests enhances security and reduces the risk of JSON hijacking. However, note that using only the POST method is not foolproof. Applications should also implement other security practices, such as HTTPS, Content Security Policy (CSP), and ensuring server response headers include appropriate CORS (Cross-Origin Resource Sharing) policies. When discussing JSON hijacking, we typically refer to an attack where attackers place malicious code on a seemingly legitimate website to trick the user's browser into executing JSON data loaded from other sources (usually trusted by the victim). Such attacks often rely on the use of the <script> tag, as it can load resources across domains.
In early cases of JSON hijacking, attackers could exploit certain features of the <script> tag to request a URL returning JSON data and then intercept and use this data using JSONP (JSON with Padding) or other techniques. If the data contains sensitive information, attackers may abuse it.
Using the HTTP POST method enhances security primarily for the following reasons:
-
Not GET Requests: The
<script>tag is typically used to initiate GET requests when loading resources, not POST requests. Since JSON hijacking often involves the use of the<script>tag, JSON data returned via POST requests cannot be directly utilized by such tags. This means that merely embedding<script src=". ..">on a malicious site does not allow attackers to directly retrieve data from another domain. -
Requires a Body: POST requests typically include a request body, whereas GET requests do not. Since JSON hijacking involves attackers not controlling cross-origin requests, they cannot control the request body content of POST requests, which creates a barrier for attackers.
-
CSRF Token: Using POST requests enables Cross-Site Request Forgery (CSRF) protection. Typically, the server generates a CSRF token and sends it to the client. The client includes this token as part of the POST request. The server verifies the token; if the request lacks the correct token or it does not match, the request is rejected. This prevents attackers from forging requests.
-
Additional Security Measures: Compared to GET requests, POST requests are easier to integrate with other security measures, such as
Content-Typevalidation in HTTP headers. If the server expectsapplication/jsondata, attackers find it difficult to forge this type in browser-initiated requests, as cross-origin policies typically restrict setting certain headers.
For example, suppose an API endpoint returns sensitive JSON data. To prevent JSON hijacking, make it accept only POST requests and require a valid CSRF token in the request body. This way, even if attackers know the API endpoint, they cannot retrieve data merely by embedding <script> tags on their site, as they cannot trigger POST requests or bypass CSRF protection.
Overall, while using the POST method is not absolutely secure, it does enhance security by limiting and increasing the obstacles attackers must overcome. Developers must also combine other security best practices, such as using HTTPS, ensuring API interfaces correctly validate inputs, and restricting the leniency of CORS policies, to build more secure web applications.