location.__defineGetter__('host',function(){return 'google.com'})
undefined
location.host
"google.com"
On Saturday, November 30, 2013 9:45:38 AM UTC+7, Godfrey Chan wrote:
>
>
> 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 <hom...@gmail.com<javascript:>
> > 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-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.
