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.

  • 5
  • What you are describing is not CSRF.
    – rook
    Sep 3, 2016 at 7:33
  • @rook - I was confident it could be classified as CSRF because the JSON is authorized in some way (cookies), yet, i guess, this also explains why I could not find a good explanation by googling. I have revamped the question text to remove the incorrect references, sorry for that. Can I just ask you how I classify this attack? (pretty please >^.^<)
    – grochmal
    Sep 3, 2016 at 18:14
  • @grochmal It is a same-origin policy bypass. In the context of json, it is called 'json hijacking' which is similar to 'jsonp hijacking' (in this case there is no padding). CSRF is always blind, content hijacking attacks provide vision.
    – rook
    Sep 4, 2016 at 8:34

2 Answers 2


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.

  • Eyup, that explains it. I completely forgot that JavaScript is prototype based, akin of, say, io. I do not if it may be polite to add to the answer that Alexander added this as a comment. Nevertheless, this is exactly what I was looking for.
    – grochmal
    Sep 3, 2016 at 18:17

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.

  • I have revamped the question. It was my mistake to include CSRF. Yet, it also explains why I could not find the answer by sing google. A CSRF attack usually involves inducing a change on the victims account is still a valid statement (for someone that may find this question by googling), since I had (erroneously) titled the question as CSRF before.
    – grochmal
    Sep 3, 2016 at 18:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .