Re:JSON Hijacking - vulnerability in some GET situations
by int2e on Friday June 26, 2009 @01:58PM
(#675782)
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...
Re:JSON Hijacking - vulnerability in some GET situations
by sh1mmer on Friday June 26, 2009 @04:37PM
(#676077)
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.
http://www.matasano.com/log/672/di-paolas-prototype-injectio...
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...
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.