DEV Community

Why Facebook's api starts with a for loop

Antony Garand on November 13, 2018

If you ever inspected your requests to big company's API's in the browser, you might have noticed some weird javascript before the JSON itself: F...

Read full post

Ben Halpern • Nov 13 '18

This is incredibly illuminating. Thank you so much for this Antony!

raphipsp • Nov 14 '18

Replace var x with an html script tag?
But how?

Antony Garand • Nov 14 '18

In your webpage, you would do the following:

<script>
function Array(){
    alert('You created an array!');
}
</script>
<script src="https://gmail.com/messages"></script>

This way you overload the constructor before loading the messages themselves.

raphipsp • Nov 14 '18

Ah ok, I see.
I think the way it is written in the article is confusing. It should instead say "override the Array constructor before loading external scripts"

Antony Garand • Nov 14 '18

Thanks for the feedback, updated the post so it's more clear

raphipsp • Nov 14 '18

Wow you're fast!

Beni Cherniavsky-Paskin • Nov 20 '18

Is this all only to protect people that misuse eval() to parse JSON? JSON.parse() has never been affected by any of this, right?

Hmm, the article gives example of malicious site loading the JSON API directly with a script tag: <script src="https://gmail.com/messages"></script>.
So here's where I'm confused:

Why would a differed site have authentication to get answers from the API using a script tag?
If it works with a script tag and hacks to extract data from evaluating JSON as JS, why won't it work anyway with an AJAX request, parsing the result however you want?

Is this because script tags are historically lax about same-origin policies? I knew evil.example.com can include a script tag for gmail.com, but does that also give such request access to gmail.com cookies?!?

Alex Lohr • Nov 20 '18

a script tag will basically send the same request that would be sent if the URL itself was loaded in the browser - if the browser has cookies saved for the URL, they will be sent and thus authentication cookies can successfully be validated.
because AJAX requests are discarded by the browser unless the correct Cross Origin Resource Sharing (CORS) headers are set on the server, so you won't get the result.

While it is absolutely possible to implement a strict security layer on an API server, this will also increase the CPU/memory/bandwidth requirements. If you have a really big service such as gmail, you'd rather do as much security as possible on the front-end level.

Miff • Nov 13 '18

I'm really wondering how any of these attack techniques would fare against simpler CSRF techniques like double-submitted cookies.

Other stupid ways that seem like they could mitigate this would be to just make all the JSON endpoints require a POST, or to use a different method of encoding data that can't be interpreted as valid Javascript at all (XML?)

Nathan Johnson • Nov 15 '18

Making them all POST wouldn't be semantic (POST means you're changing something on the server). JSON is the standard API data format now, and it's much better than XML in my opinion.

The ultimate way to prevent these attacks is to not allow user submitted input to end up anywhere in output unescaped so attackers' scripts are never able to be injected.

Richard Tallent • Dec 9 '18

No one cares about semantics verbs. Using POST for API endpoints solves an entire class of link-based attacks. We should of course still use CSRF and other mitigations, but the semantic purism argument is a weak one, IMHO.

Guney Ozsan • Nov 23 '18

Not POST but using header authentication an all endpoints can add a layer of security. But this is extra. Nathan's point is well told.

Joshua Arnott • Nov 14 '18 • Edited

I can see how adding an infinite for-loop at the start of the JSON response would prevent it from being executed as JavaScript. How does the original site access the data? Does it need to use a function to discard the first X bytes of every response before loading the JSON? Or is there something I'm missing?

Antony Garand • Nov 14 '18

This is exactly it!

As they load the string version of the JSON, they can remove their JS breaking mechanism before parsing it

Manda Putra • Nov 19 '18

I just follow along your articles with devs tool open haha

Davis • Dec 26 '18

TLDR: use Auth Headers instead of cookies in your API and don't use script tags to call an API?? We shouldnt be looking at the hacks that giants use and instead use actual security improvements. CSP headers!

Antony Garand • Dec 29 '18

This was about 10 years ago, when CORS and CSP didn't exist

Michael Z • Jan 28 '21

While those vectors may not be working today, we never know what new bug tomorrow will bring, and therefore we should still do our best to prevent API's from being exploitable.

Wouldn't CORB prevent JSON hijacking in modern browers? developers.google.com/web/updates/...

Alexey • Nov 14 '18

If you have some js on your site, that can modify your constructor, you already hijacked, isn't it?

Antony Garand • Nov 14 '18

This attack is used to steal data from another website.

Say you're on dev.to, you don't want dev.to to access your emails!
But dev.to can still execute their own scripts, which makes sense.

Luke Vo • Nov 14 '18 • Edited

Pardon my noob but shouldn't it be fixed with CORS instead?

Antony Garand • Nov 14 '18

Cors wouldn't work on old browsers, and CORS is also used on the source site to limit what can be accessed from this website.

What is happening here is the opposite: An attacking website want to access information from another one.

Also note that this vulnerability is over 10 years old, well older than CORS :)

Templar++ • Jan 2 '19

Amazing article. Thank you!

Alex Lohr • Nov 14 '18

I did something similar, but I used location.href=... to redirect to the site from which the data was supposed to be used.

Gerasimos (Makis) Maropoulos • Nov 13 '18

Amazing, I knew some of those individually however this extremely helpful post is like a complete paper with references, so I can bookmark this, thank you Antony!