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