Thanks for the explanation. I now better understand the point you made in
your original argument and the security concern you raised.
> >GET requests using Cookies for authentication. That returns non-public
data.
> most of the time this is the case. JS templates return whole forms with
authenticity_token in it!
My point here is not that "JS endpoints that uses cookie + return private
data" isn't a common misuse, that I'm sure you are more qualified to give
an opinion than I do, based on the apps you work on. My point is I don't
think that this is inherently flawed and fundamentally impossible to fix
(and hence we *must* remove it). Not using cookies for auth is one possible
way to fix, but as you pointed out...
> Not using cookies for JS responses breaks the idea of templating. For API
people should use JSON(P). Why JS?
And I think you are quite right. Having to deal with alternative
authentication scheme that does not rely (only) on cookies, on both the
client and the server side, probably cancels out a lot of the benefits of
using JS responses (simplicity etc).
However, I think there are probably something else that Rails can do to fix
the security concerns you have. For example, we can automatically wrap all
JS responses with something like...
if(<%= an_array_of_whitelisted_hosts %>.indexOf(window.location.host) > 0){
// ... the actual response goes here ...
}
What do you think about this? It seems like this would be quite easy for
Rails to implement. We can turn this on by default with the list defaults
to request.host and provide a way to opt out. Would that address your
concerns?
Again, I personally don't use this feature, so I don't have a strong
opinion on whether it should be kept in core. I'm just focusing on the
security concerns you raised and see what we can do to make Rails better.
And I suspect there are ways to make this feature more secure by default
without removing it.
Godfrey
On Fri, Nov 29, 2013 at 6:05 PM, Egor Homakov <homa...@gmail.com> wrote:
> It's not very proper comparison. Nobody uses JSOPN w/o *a reason*.
> Autocomplete, as maximum. And security concern of jSONP is way more known
> than RJS bug (did you see articles on this topic but mine?)
>
> >Maybe we should improve the documentation to point out that you should
> not be using cookies to authenticate "private" JSONP/JS endpoints
> IMO, it should be fixed somewhere in code, not in documentation. People
> don't read it periodically.
> Not using cookies for JS responses breaks the idea of templating. For API
> people should use JSON(P). Why JS?
>
>
> On Saturday, November 30, 2013 7:43:51 AM UTC+7, Godfrey Chan wrote:
>
>> Right, I agree that if used incorrectly this be a vector for CSRF attacks.
>> But like you said, this is also a problem for JSONP, which is by far way
>> more popular. So unless we also remove JSONP there problem you are
>> complaining is still there, no?
>>
>> Maybe we should improve the documentation to point out that you should
>> not be using cookies to authenticate "private" JSONP/JS endpoints? Perhaps
>> we can make it easier to do token-based authentication for API requests?
>>
>> Because personally I don't see JSONP going away.
>>
>> Godfrey
>>
>>
>> On Fri, Nov 29, 2013 at 2:55 AM, Egor Homakov <hom...@gmail.com> wrote:
>>
>>> Focus on security concern. I repeat - any GET accessible .js.erb IS a
>>> vulnerability because leaks all data it has inside.
>>> All "i use it because it's fast/convenient" means nothing if it's a
>>> vulnerable technique. IMO
>>>
>>>
>>> On Thursday, November 28, 2013 3:41:37 PM UTC+7, 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.co
>>>> m/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 rubyonrails-co...@googlegroups.com.
>>> To post to this group, send email to rubyonra...@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.
>
--
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.
