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