3 ms·
I can't speak for JSON, but can someone try the same for JSONp[1], which many (legit) services use to bypass the same-origin policy? For example, Your app
by neya 14y ago
I can't speak for JSON, but can someone try the same for JSONp[1], which many (legit) services use to bypass the same-origin policy?
For example,
Your app - sends request -> Third party service
Third party service - replies -> JSONp response
Evil website's script on your app -> Hijack/modifies JSONp response -> steals credentials.
Is this possible? In all probability, it should be possible, right?
[1]It's a loophole (kind of) for executing Javascript across different domains.
http://en.wikipedia.org/wiki/JSONP http://en.wikipedia.org/wiki/JSONP
- fmavituna 14y agoYes it's indeed correct and document. CORS safely solves this problem. http://en.wikipedia.org/wiki/Cross-origin_resource_sharing http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
- neya 14y agoWow, thanks mate! I never knew of CORS before.. (I admit).
- jcampbell1 14y agoCORS does nothing to address this problem. If you expose private data via CORS or JSONP you face the exact same problem. CORS solves a different problem, in that you don't have to eval 3rd party code. If the remote service provider gets hacked, then your site may not get compromised.
- fmavituna 14y agoThe issue is an external file can be called from a 3rd party website via "<script src=" and if the format is something that JavaScript interpreter understands then it's possible to hijack the data (so called JavaScript/JSON Hijacking). CORS solves it because you can WHITELIST the domains that can access the data, which is huge! Just like crossdomain.xml in Flash and ContenPolicy in Silverlight. You are right though if the format is still JSON you are still vulnerable to the same attack, however CORS doesn't require you to use any format particularly, so it's possibly to use any other data format.