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