
JSON Hijacking - vulnerability in some GET situations - FluidDjango
http://haacked.com/archive/2009/06/25/json-hijacking.aspx
======
tptacek
This is Stephan Di Paola's "Prototype Hijacking" attack, and it's more than 2
years old. We wrote it up here:

[http://www.matasano.com/log/672/di-paolas-prototype-
injectio...](http://www.matasano.com/log/672/di-paolas-prototype-injection-
attack/)

~~~
int2e
Yeah, XSSI has been well known for a while.

This article's argument against using custom headers is a bit bunk. If you're
not properly disabling proxy caching for sensitive data, you're asking for
trouble anyways. Disabling caching properly is a bit tricky, but there are
some useful details here:
[http://code.google.com/p/browsersec/wiki/Part2#Document_cach...](http://code.google.com/p/browsersec/wiki/Part2#Document_caching)

~~~
int2e
Perhaps there are some interesting corner-cases where the browser will locally
cache the JSON. Time to go play with it...

------
sh1mmer
For some more practical advice, this is the point of using crumbs, kids.

If you pass a unique verifiable value with your request you can avoid this
sort of thing. This is also true of any GET request that can change user data
(which you shouldn't be doing anyway).

A typical way to do this is to hash some secret for the user with a salt and a
timestamp. The timestamp and the secret are passed with the request and can be
used to verify the secret.

