prepend jsonp callbacks with a comment to prevent the rosetta-flash vulnerability #1766
Conversation
prepend jsonp callbacks with a comment to prevent the rosetta-flash vulnerability
| @@ -1011,7 +1011,7 @@ describe('Response', function () { | |||
|
|
|||
| server.inject('/?callback=me', function (res) { | |||
|
|
|||
| expect(res.payload).to.equal('me({"some":"value"});'); | |||
| expect(res.payload).to.equal('/**/me({"some":"value"});'); | |||
| expect(res.headers['content-length']).to.equal(21); | |||
There was a problem hiding this comment.
JSON-P responses should also get an X-Content-Type-Options: nosniff header, just in case. This would have prevented the Rosetta Flash vulnerability too, in modern browsers, and it might prevent similar attacks that bypass the /**/-based protection in the future.
See https://gist.github.com/mathiasbynens/5547352 for an example in PHP (LOLWAT, I know).
There was a problem hiding this comment.
That header can be added by setting
{
security: {
noSniff: true
}
}in your server options.
Or with several other security related headers by just setting { security: true }.
Just to remind people that this functionality does exist.
There was a problem hiding this comment.
Do you think it would make sense to enable this header by default for JSON-P responses?
There was a problem hiding this comment.
For a while I think @hueniverse was debating enabling all of the security headers by default. I'm not sure how he feels about this.
There was a problem hiding this comment.
I'll submit another PR and we can find out :]
background
tl:dr - someone created a alphanum only swf converter, which means that they can in theory use it as a callback at a JSONP endpoint, and as a result, send data across domains.
Prepending callbacks with an empty inline comment breaks the flash parser, and prevents the issue. This is how google, facebook, github, et al are handeling it.
CVE-2014-4671A