Abusing JSONP with Rosetta Flash(miki.it)
miki.it
Abusing JSONP with Rosetta Flash
http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/
6 comments
> There is one drawback though--it requires that a pmxdr host endpoint be on the target domain
That's one substantial drawback.
That's one substantial drawback.
Unfortunately: http://blog.algolia.com/jsonp-still-mandatory/
this is one of those times where the people using badly configured proxies just need to live with a broken internet rather than drag the rest of us down
This is a really, really nasty attack. If you allow JSONP on your domain you are almost certainly vulnerable.
Given the nastiness of this attack (a fully interactive client-side backdoor!), the non-trivial nature of the algorithms and coding theory required, and the slow uptake of Flash patches especially in enterprise [1], this seems like downright irresponsible disclosure to share such a detailed post (with a repository and detailed instructions for script kiddies!) so quickly after notifying companies. I can understand all too well how excited the researcher must have been to discover this and share it with the world, but jeez: wait until the Flash patch hits an inflection point on the adoption curve at least!
[1](http://krebsonsecurity.com/2014/05/the-mad-mad-dash-to-updat...)
[1](http://krebsonsecurity.com/2014/05/the-mad-mad-dash-to-updat...)
Nice to see the exploit finally out.
I gave a talk about the potential for this to happen about a year ago: http://quaxio.com/jsonp_handcrafted_flash_files/
I gave a talk about the potential for this to happen about a year ago: http://quaxio.com/jsonp_handcrafted_flash_files/
People have known about the potential for much longer than a year:
http://www.slideshare.net/guest2821a2/web-browsers-and-other...
http://www.slideshare.net/guest2821a2/web-browsers-and-other...
Actually going out and doing it is something else.
http://www.slideshare.net/guest2821a2/web-browsers-and-other...
http://www.slideshare.net/guest2821a2/web-browsers-and-other...
Actually going out and doing it is something else.
The article suggests a 32 character length limit on callback parameters. Unfortunately this looks to be too short - from examining log files it appears jQuery often uses callbacks of 40 or even 44 characters.
Why is JSONP any less than an XSS exploit waiting to happen?
I don't think you can use JSONP for XSS. The JavaScript does to execute on the domain that hosts the JS, it executes in the context of the page that loaded the code using a script tag. Allowing attacker-controlled script tags is definitely an XSS hole.
The linked article demonstrates even just allowing attacker-controlled function name can allow an XSS hole!
That's due to an extremely complex (albeit easy to exploit) SWF reflection attack.
JSONP itself, though yucky, should still be safe from XSS given a /-star-star-/ prefix and a validated callback parameter.
JSONP itself, though yucky, should still be safe from XSS given a /-star-star-/ prefix and a validated callback parameter.
> given a /-star-star-/ prefix and a validated callback parameter.
I think that is the "waiting to happen" part of my initial comment.
I think that is the "waiting to happen" part of my initial comment.
It seems to me that the real problem is that flash has access to browser cookies without following the browser security model.
> if possible use a dedicated sandbox domain.
It's 2014. You don't have to use JSONP and open up your domain to XSS; just use standard and safe XHR with CORS[1]. Every major browser has supported it for years, and for very old browsers that don't support CORS (IE 8), I wrote pmxdr[2] five years ago.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...
[2]: https://github.com/eligrey/pmxdr