via JSON Hijacking

Sensitive Data Disclosure via JSON Hijacking

Overview of the Vulnerability

Sensitive data can be exposed when it is not behind an authorization barrier. When this information is exposed it can place the application at further risk of compromise. JSON Hijacking allows a malicious attacker to exfiltrate sensitive data using Cross Site Request Forgery (CSRF) and overriding the Object prototype by using __defineSetter__.

This application is susceptible to JSON hijacking which enables an attacker to retrieve sensitive data by tricking a user to click on a crafted link. Once a user clicks on the link, data from the user’s account is read and passed to the attacker. This allows an attacker to collect Personally Identifiable Information (PII) and sensitive metadata to escalate privileges or launch phishing campaigns on targeted users.

Business Impact

When an application fails to mask internal IP addresses it leaves the internal network more susceptible to future network based attacks.

Steps to Reproduce

  1. Host the following payload on the attacker server:

{{payload}}

  1. Make a request on behalf of the user to the attacker served file:

{{screenshot}}

  1. Observe that the user requested data from the vulnerable endpoint and the response is in JSON

  2. On the attacker hosted server, look at the logs to see that the JSON was successfully exfiltrated:

{{screenshot}}

Proof of Concept (PoC)

The following screenshot shows the sensitive data disclosed:

{{screenshot}}

Recommendation(s)

To prevent JSON hijacking from occurring, the following configurations can be set:

  • Enable CSRF protections by requiring a predefined, random value for all JSON requests

  • Only return JSON objects through HTTP POST requests, as script tags will only generate through HTTP GET requests

  • Do not let web browsers interpret JSON objects as valid JavaScript code

It is recommended to encrypt sensitive data both when at rest and when in transit. All data that is processed, stored, and transmitted by the application should be classified by business need, regulatory and industry requirements, and appropriate privacy laws.

Additionally, it is best practice to not store sensitive data when it is no longer required, as data that is not retained cannot be accessed and used maliciously. All sensitive data should therefore be a part of a regularly reviewed maintenance cycle. This review cycle should include rotation of secrets.

For more information refer to Open Web Application Security Project (OWASP) guide relating to this vulnerability: https://owasp.org/www-project-proactive-controls/v3/en/c8-protect-data-everywhere

PreviousInternal IP Address DisclosureNextvia Mixed Conten

Last updated