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 moving these type of processing to the client”, then fine. But I am not sure if I fully understand the security angle here.
Specifically, in Egor’s blog post:
- “Broken concept & architecture. This feels as weird as the client-side sending code that is going to be evaled on the server-side… wait… Rails programmers had similar thing for a while :/”
So I’ll have to assume you are talking about eval()-ing code that contains user-supplied data that’s bad. Which is fair enough, considering there’s usually a safer way to do this (encoding the user-supplied data as JSON first).
But as Andrew pointed out on the Github issue, there might be legitimate use cases for using this to return code that does NOT contain user-supplied data. I think those use cases needs to be understood properly (and we need to investigate/suggest alternatives for those cases) to ensure we are not removing a useful feature just because it’s subject to abuse.
If it is already possible to correctly escape input for use in the JS responder, just that it’s difficult to do it correctly, the problem might not lie in the JS responder pre-se and we should take this opportunity to address them.
I assume you are talking about CSRF attacks where a page on a third-party domain can make requests to your site on your user’s behalf. But like you said, this problem also exists in JSONP. In fact, it’s probably much easier to exploit this in JSONP (because you can control the name of the callback) than a JS response that updates a certain part of the page. So I’m not sure if this is really JS responder’s fault. And like Andrew said, in his use case there’s nothing to leak.
Maybe I am not understanding this point correctly. If you can provide some examples based on the apps you see in the field it will be very helpful.
- “UPD as pointed out on HN evaling response will mess with your global namespace and there is no way to jump into closure you created request in…”
(I suppose this is not related to security.)
I don’t do this, so I’m not really in a good position to defend it. Again, maybe it’s just a case of “no one uses this anymore so it’s not worth supporting”, and that’s fine by me. But you brought up security, so I want to make sure we address your concerns properly.