JSON through <script src=, how do you get the JS object in the rogue page?

Question

I was explaining the attack on a JSON REST API the other day (in real life, at work, not here), and I figured out that I do not understand part of the attack vector.

Sorry if this is quite a basic question, I'm not great with JavaScript.

A common way that this attack happens is that you have an API at, say http://myfavouritebank.com/api/account/ that returns the following on a GET request:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: ...

{ "customer name": "Bob",
  "account number": 123,
  "balance" : 123.56
}

This will be returned when the user is logged in (say, using a cookie based auth). When the user is not logged in it simply returns 403.

Then, a rouge page, contains:

<script src="http://myfavouritebank.com/api/account/" />

And the rogue page will load the JSON object (given that the user is currently logged in the bank's website).

But the question is

How does the rogue page actually makes use of that object? It is just an orphan object inside the script environment, how can it be assigned to a variable for example?

In other words, I figured out that I never understood how this attack unfolds from here.

---

_{There are several great answers on how to prevent CSRF on a REAST API that explain sending the data as JSON. I am trying to understand how the rogue page is constructed to retrieve the data from such a JSON, with this information I can better explain the attack.}

Answer 1

See this question for more detail, but in short, tampering with the prototypes of Object and Array can let you read out the contents of any object as it's created. So an attacker doctors the prototypes, document.write's the script tag, and even though the JSON object is not saved, the attacker's instrumentation gets notified as each property is set and can make a copy.

Answer 2

A CSRF attack usually involves inducing a change on the victims account, under the custody of the vulnerable site, rather than extracting information about the victims account. That is, the attack centers around implementation details of the vulnerable site, rather than data details of the victim. Knowing or extracting information about the victim is not necessary.

A vulnerable site has an endpoint, like /transfer-funds/, which takes parameters indicating which account to which funds should be transferred, an amount to transfer, and performs the transfer from the authenticated users account. Make sense?

If the authenticated users account was identified by the cookie issued by the vulnerable site, an attacker merely had to construct a form on a page they control that POSTs to the vulnerable endpoint and then induce the user to click a button firing off the POST.

The browser would include the cookies in the request despite the request being initiated from a different site, and on submission, funds would magically and unfortunately be transferred as though the request was initiated by the victim.

This cross-site data submission with credentials, with many variations on the specific naive scenario above, was by default allowed for a very long time, and is still a common pattern on the web. Attacks have had to be specifically blocked or defended against, rather than valid usage specifically and narrowly allowed.

Much has changed since the attack was first identified to increase the baseline security level, but at the cost of dramatically increasing the configuration load and complexity involved in maintaining safety in all known scenarios.