3 ms·

The obvious mitigation is don't visit untrusted endpoints from your API client, and/or don't run a script interpreter inside your API client.

• foota 10y ago
  That's not what the vulnerability is here. If you have a server endpoint that returns an array without wrapping it as a property on an object then an attacker can write a webpage that overrides the Array prototype and requests the json from your page as a script, thereby bypassing the cross origin check it would be subject to as an xhr request. So if you have a page which returns sensitive information as an array you (were, it seems browsers probably don't allow you to override the array prototype anymore) are vulnerable to the attacker stealing a signed in users secrets.
  • niftich 10y ago
    On the contrary, that's precisely the vulnerability: 1. The API server needs authentication, which gets cached in the user-agent. 2. The same user-agent, with the same authentication context, is then directed to a malicious site. 3. The user-agent contains a javascript interpreter, and the malicious website serves a script to override the Array prototype. 4. The same script then executes a CSRF request to the API server, reusing the cached authentication context, and therefore stealing the response. A browser fits all the necessary conditions that must exist for this vulnerability to be exploited, but if you're the consumer of the API, you don't have to use a browser as your user-agent. You can write your own, which you'd do if you're making these requests programmatically in a non-web application. Regardless as to which user-agent you use, a viable mitigation is to not visit untrusted endpoints with the same cookie jar or authentication context. Another viable mitigation is to omit including a script interpreter in your custom API client. This is in fact usually the case.
    • foota 10y ago
      Sorry, you are right.