So you say Egor if rails would raise an error when the request for a js format is not xhr? it would solve the security issue?
On Monday, December 2, 2013 4:41:58 PM UTC+1, Egor Homakov wrote: > > What do you mean? Hijacking issue was just same, browsers were same, and I > recall XHR could add additional headers.. so while(1) sounds like weird > idea > > On Monday, December 2, 2013 10:35:16 PM UTC+7, Rodrigo Rosenfeld Rosas > wrote: >> >> Yes, it makes sense, because you're forced to use XHR anyway when you >> include a "while(1);" otherwise you won't be able to strip it out. >> >> Maybe the reason was to protect against old browsers that didn't >> implement proper same-origin policy? >> >> Em 02-12-2013 13:30, Egor Homakov escreveu: >> >> -1 for while(true). Let's consider all use cases >> >> 1) JS templates are used with AJAX, thus the X-Requested_with header is >> sent and .xhr? is enough protection >> 2) JS templates are also used with inline <script> tags. Thus while(true) >> will both break on origin website and on attacker's website. Not an option >> 3) Since we can send additional header why bother with prepending >> while(true); >> So .xhr? is most elegant way that covers most of attack vectors. >> I really don't understand why JSON-hijacking wasn't solved the same way. >> while(true) is uglyish >> >> On Monday, December 2, 2013 10:24:30 PM UTC+7, Rodrigo Rosenfeld Rosas >> wrote: >>> >>> I believe the reason why it's hard for us to understand how the exploit >>> works is because it's pretty hard to find the documentation for RJS >>> itself and specially how it works... >>> >>> I'm assuming, it works like JSONP, since Egor must know what he is >>> talking about. >>> >>> In this case, it won't require a XHR request and won't send any nonce >>> (like the XSRF token) for GET requests, and will work with a regular >>> inline script tag. >>> >>> In that case, the trick of prepending a "while(1)" would probably fix >>> this particular issue because it wouldn't allow the code to be >>> evaluated, no matter whether you have changed the JS global context or >>> not. >>> >>> Another way of fixing it if I understood correctly would be to require >>> all RJS requests to happen with XHR since they are subject to >>> same-origin browser's policy. >>> >>> Yet another way to fix it would be to always require a nonce even for >>> GET requests to XHR templates requests. >>> >>> Am I missing something? >>> >>> Best, >>> Rodrigo. >>> >>> Em 02-12-2013 12:57, Greg Molnar escreveu: >>> > I think we should rather try to find a way to make this secure. What >>> > would be a sane default? Only respond to js format is the request is >>> xhr? >>> > To be honest I read Egor's post but still not sure how this exploit >>> > would work. I will look at his examples when I got some free time and >>> > hopefully that will help to understand it more. >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
