labmlai
JSONP and reflected flash file (new flaw to possibly check for)
There's a same-origin bypass made possible by reflecting a user-supplied param as the first thing in a response body. More info here: http://quaxio.com/jsonp_handcrafted_flash_files/
Basically, if you return a user-supplied value as the first thing in a response body (as is usually the case for JSONP responses), the param can be made to be a valid SWF file. If this page is used in a <object src="http://foo.com/endpoint.json?callback=...swf file..."> tag, the swf reflected by foo.com will have same-origin access to foo.com, allowing it to read csrf token, etc.
I'm not sure what would be the best way to detect this, but in my case the vulnerable app was doing something like this:
response.body = "#{param[:callback]}"
Recommended fix: the recommended fix is to (1) add a javascript comment before the reflected callback name and (2) limit the callback name length to a short size (32 characters or so). A non-vulnerable response would look like this: response.body = "/**/#{param[:callback]}".
Sanitizing the parameter name to make sure it contains only alpha numerical values is not enough.
render :json => resource, :callback => params[:callback] is the built-in way for JSON responses.
https://github.com/rails/rails/pull/16109 is supposed to fix this, but I don't see the comment when using the above code.
This is kind of fixed on the client-side at this point, although I guess that presumes people update flash/browsers.
Yeah, this was fixed in rails recently, but only if you use the jsonp response helper, which doesn't prevent someone from doing response.body = "#{param[:foo]}". The response doesn't have to be json (afaik flash ignores the content type).
A new bypass for the client-side fixes has been found as well. http://topolik-at-work.blogspot.com/2015/06/cve-2015-3096-rosetta-flash-fix-bypass.html
@jjarmoc this is the same flaw. I opened this issue before it was named "rosetta flash".
I'm aware the flaw predates that name, I was commenting in regards to the discussion earlier that it's "kind of fixed client side."
Interested as well for this, though for a similar attack vector for reflected file download attack https://drive.google.com/file/d/0B0KLoHg_gR_XQnV4RVhlNl96MHM/view
Reference: https://www.trustwave.com/Resources/SpiderLabs-Blog/Reflected-File-Download---A-New-Web-Attack-Vector/ https://www.blackhat.com/docs/eu-14/materials/eu-14-Hafif-Reflected-File-Download-A-New-Web-Attack-Vector.pdf
RFD requires the attacker to be able to set the downloaded file extension, right? I'm not sure how Brakeman would be able to detect that.
True, but reflecting any sort of input back to the user is something it might be able detect?