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 rubyonrails-co...@googlegroups.com <javascript:>. > To post to this group, send email to rubyonra...@googlegroups.com<javascript:> > . > 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 rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
