On 2 Dec 2013, at 03:42, Egor Homakov homa...@gmail.com wrote:
What I actually want is to make people understand and check if they have this
problem. Deprecation is on of the means to do it.
No, it isn't. Deprecation means we intend to remove that feature in the next
major release, which we
The mechanics of the vulnerability, which Egor's blog does not really
communicate effectively, are, as I understand them:
an evil site includes a script tag referencing a GETable .js.erb url from
a good site. If the user is logged into the good site via cookies and has
3rd party cookies
On 2 December 2013 09:09, Alex alxtsk...@gmail.com wrote:
This attack is not possible with non js content loaded by XHR or iframes,
as the browser enforces cross-domain restrictions for both, and evil site
will not be able to get at good site's content.
If the operators of EvilSite have gone
On 2 Dec 2013, at 09:32, Michael Pavling pavl...@gmail.com wrote:
On 2 December 2013 09:09, Alex alxtsk...@gmail.com wrote:
This attack is not possible with non js content loaded by XHR or iframes, as
the browser enforces cross-domain restrictions for both, and evil site will
not be able
If the security concern is only about CSRF, what about not rendering CSRF token
in templates at all?
I mean, UJS may solve this problem appending the CRSF token from meta tag.
If that’s not elegant since it will require javascript, even for static forms,
we may do that only for .js.erb views.
I'm afraid the CSRF token is not the only private data that could be
sent in the template.
I'm actually surprised so many applications seem to use RJS, including
some applications I do use, like Redmine or GitLab.
Maybe I should create the habit of using an anonymous session for
regular
The mechanics of the vulnerability, which Egor's blog does not really
communicate effectively
what's not effective in my post? As I said attack works as JSONP hijacking.
So everything is totally obvious, isn't it.
On Monday, December 2, 2013 4:09:02 PM UTC+7, Alex wrote:
The mechanics of the
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
I see, extracting it as a gem fix the problem, at least for the rails itself,
which is what we want.
The extracted gem must explicitly explain the security concerns on the top of
README, regardless of people usually don’t read it.
Rails already did that for other features, for other reasons
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
-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
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
What do you mean? Hijacking issue was just same, browsers were same, and I
recall XHR could add additional headers.. so while(1) sounds like weird
idea
On Monday, December 2, 2013 10:35:16 PM UTC+7, Rodrigo Rosenfeld Rosas
wrote:
Yes, it makes sense, because you're forced to use XHR anyway
So you say Egor if rails would raise an error when the request for a js
format is not xhr? it would solve the security issue?
On Monday, December 2, 2013 4:41:58 PM UTC+1, Egor Homakov wrote:
What do you mean? Hijacking issue was just same, browsers were same, and I
recall XHR could add
David, first I must say I admire both you and Homakov and I'd certainly
hire him if I could afford it.
I believe what led him to create that post was exactly your reponse to
his e-mail.
I agree he shouldn't have created this discussion publicly but you
shouldn't have replied the way you did
Rodrigo, many great things around the word can be dangerous if used in the
wrong way but there are great people who try to make the usage of tools
secure so humanity can profit from them.
I am not the fun of don't use this or that because it can be dangerous.
Let's find a way to make it
What email is that? I replied to Homakov on Twitter thanking him for the
discovery and stating a clear intent to get the issue resolved. What I rejected
outright was the knee-jerk reaction to remove the possibility of generating JS
responses from Rails. This rejection was confirmed when it got
Your first message in this thread. He even quoted the relevant part in
his article:
Not only are js.erb templates not deprecated, they are a great way to
develop an application with Ajax responses where you can reuse your
server-side templates. It's fine to explore ways to make this more
There's a precise reason why I did so called full disclosure
I started writing an email to security@37singals, then i checked out the
previous conversation we had, where i was asked about my link for Hall of
Fame. I gave the link and after a month it wasn't added. No, i don't really
care, but
I feel entirely comfortable with shooting down REMOVE THE FEATURE as the first
response to any security reporting. Our response should be, as it was here --
as it always is, let's fix the issue. This is doubly so when security
reportings are conflated with other architectural agendas, like
I'm sorry that you weren't added to the hall of fame in a timely manner, and
I'll check into what happened, but that hardly justifies this shotgun approach
to disclosure. Had you also contacted the other application makers for which
you provided 0-day attacks? Did they also slight you in some
Homakov rejected outright initially as a possibility
https://twitter.com/homakov/status/406466616897986560
Sorry for using REMOVE THE FEATURE wordings, now I see how it sounded.
All i wanted is to fix security bug itself, throwing the feature away
wasn't my goal.
On Monday, December 2, 2013
Homakov, what we all want is to fix security bugs. There isn't any
justification for thinking that we aren't all in the same boat on that. Things
get muddy when you hinge the reporting of a security issue to your personal
assessment of what a good architectural pattern is, though.
So please. I
In this thread it has been repeated several times that .js endpoints via
GET are a security breach. And that people should stick to JSON.
Let me make clear for the archives that is not generally the case. There
are valid use cases for dynamically generated public JavaScript, for
example when your
Xavier, absolutely. Javan has suggested we have something like
protect_from_forgery, which can be opt-out of on a per action/controller basis.
On Dec 2, 2013, at 10:12 AM, Xavier Noria f...@hashref.com wrote:
In this thread it has been repeated several times that .js endpoints via GET
are a
I am trying to imagine dynamically generated public JavaScript but
nothing comes to my mind. Any small bit of information, even the fact that
user is logged in, or blocked, is somewhat sensitive IMO.
Opt-out is must-have indeed. E.g. in development env it might be convenient
to reach .json
Embeddable gists are another example: script
src=https://gist.github.com/javan/7725255.js;/script
On Monday, December 2, 2013 2:11:24 PM UTC-5, Xavier Noria wrote:
On Mon, Dec 2, 2013 at 7:43 PM, Egor Homakov hom...@gmail.comjavascript:
wrote:
I am trying to imagine dynamically generated
I much appreciate RoR, its community Homakov included. I never saw RoR
security team at least one time to appreciate Homakov's findings. Perhaps
you should take it closer by first recognize his security work over RoR.
I'm quite sure that Homakov would have comply to your rules in the end.
On
Marius, your solution is not much different from responding a render :json
: you send only the data, and the processing code is already on client
side; transponder.js seems to me that it adds an abstraction level in order
to manage the data, but it is different from RJS, which sends the execution
Sorry, I meant Zack.
--
Maurizio De Santis
2013/12/3 Maurizio De Santis desantis.mauri...@gmail.com
Marius, your solution is not much different from responding a render :json
: you send only the data, and the processing code is already on client
side; transponder.js seems to me that it
That's still OK if it's public data. (Obviously anything with a CSRF token in
it isn't.)
It'd be nice if it was more explicit though, as the vulnerable cases are not
obvious.
On 2/12/2013, at 13:59 , Anthony Richardson richo...@gmail.com wrote:
Would a solution be to prevent rails apps
On one hand if you explain/reach people with security concern of JS
templates they will most likely rewrite it to JSON-style.
On the other hand if they blindly update their rails/don't read news - the
only way to reach them is Deprecation warning. Or maybe just WARNING?
What I actually want is
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
On Thu, Nov 28, 2013 at 12:41:37AM -0800, 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
A lot of people use the js responder with ujs, but there are often bugs
with how jQuery handles the automatic code execution of js ajax responses,
so I agree, it's something I wouldn't mind deprecating.
One reason people tend to use js responders is to use js.erb to embed
values from ruby into
I am not against removing this (I personally don't have use for this
anymore), but the reason behind the removal this seems unclear to me.
If it's just let's remove this because no one uses this anymore (and if
that's true), or Rails want to discourage this type of architecture in
favour of
I believe the primary use case for js responder is remote forms, where you
are not doing the request yourself, so a js response is the simplest and
most natural approach there. This is not inherently insecure so should not
be deprecated just because it does not feel good to some.
On Thursday,
A lot of the proposed issues aren't really too bad IMO, they're mainly just
related to one developer's preferences and taste over another. I personally
don't think returning JS from an ajax call is much (if any) worse than
returning HTML. It's all just your server rendering some markup/code for
About the HTML rendering use case, I would point out that it could be
adequately solved using render_to_string, and IMHO more elegantly, since
the related JS could be included in the assets, and so organized toghether
with the other JS source.
I can't think about use cases where RJS is
I am -1 for deprecating the js responders
Personally I find using the js.erb templates much easier, more DRY and more
expressive then returning a HTML string as a JSON element. Any JavaScript
in the js.erb should be specific to initializing the rendered HTML and
would exist in the event handler
40 matches
Mail list logo
