As many have already mentioned, enforcing request.xhr? for js requests provides adequate protection. You can't set custom headers when making a cross-domain request with a <script> tag so checking for one ensures the request is local. That's what request.xhr? does.
Here's the solution we're using: https://gist.github.com/javan/7725255 I could see wrapping that up into something convenient like protect_from_forgery and making it a default in Rails. -Javan 37signals On Thursday, November 28, 2013 3:41:37 AM UTC-5, Egor Homakov wrote: > > https://github.com/rails/rails/issues/12374#issuecomment-29446761 > > Here in discussion I proposed to deprecate JS responder because this > technique is insecure and not pragmatic way to transfer data. > It can be exploited in this way > http://homakov.blogspot.com/2013/05/do-not-use-rjs-like-techniques.html > > i find this bug very often so i know what i'm talking about. With it > attacker can steal user data and authenticity_token if templates with form > were leaked too. > > > > -- 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.
