
Abusing JSONP with Rosetta Flash - moonlander
http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/
======
Sephr
The mitigation strategy falls short of current best practices.

> 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...](https://developer.mozilla.org/en-
US/docs/Web/HTTP/Access_control_CORS)

[2]: [https://github.com/eligrey/pmxdr](https://github.com/eligrey/pmxdr)

~~~
simonw
Unfortunately: [http://blog.algolia.com/jsonp-still-
mandatory/](http://blog.algolia.com/jsonp-still-mandatory/)

~~~
jes5199
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

------
simonw
This is a really, really nasty attack. If you allow JSONP on your domain you
are almost certainly vulnerable.

------
btown
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...](http://krebsonsecurity.com/2014/05/the-mad-mad-dash-to-update-
flash/#more-25957))

------
amenghra
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/](http://quaxio.com/jsonp_handcrafted_flash_files/)

~~~
Eridrus
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-
mistakes/14)

[http://www.slideshare.net/guest2821a2/web-browsers-and-
other...](http://www.slideshare.net/guest2821a2/web-browsers-and-other-
mistakes/15)

Actually going out and doing it is something else.

------
simonw
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.

------
spacemanmatt
Why is JSONP any less than an XSS exploit waiting to happen?

~~~
simonw
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.

~~~
eli
The linked article demonstrates even just allowing attacker-controlled
function name can allow an XSS hole!

~~~
simonw
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.

~~~
spacemanmatt
> given a /-star-star-/ prefix and a validated callback parameter.

I think that is the "waiting to happen" part of my initial comment.

