RJS leaking vulnerability in multiple Rails applications.

It didn't help. Now I want people to take the issue seriously. This is a huge unsolved problem.

Developers have a tool which they don't know how to properly use. So they use it how they feel convenient. It leads to security breach. Reminds mass-assignment bug (sorry, i have to mention it every day to feel important)

How it works?
Attacker redefines RJS function(s), asks authorized user to visit specially crafted page and leaks data (which the user has access to) and his authenticity_token. Very similar to how JSONP works.

Some people are +1, some found it "useful in our projects" (=vulnerable), also DHH is against my proposal:

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 secure by default, but the fundamental development style of returning JS as a response is both architecturally sound and an integral part of Rails. So that's not going anywhere.

8 comments:

DHH's comment was really unfortunate. While I've never used RJS myself, I do use some of the applications that are affected by this security exploit and I'd certainly love if Rails removed this hack (RJS) as soon as possible.

Right now I guess I should be considering using an anonymous session for general navigation to avoid having my private data in affected sites stolen by some evil site... :( Pretty sad David's position :(

If you told me that I should stop doing something in my app I'd be just thankful and would stop doing it even before I really knew why it was dangerous...

FWIW, according to CVE-2011-0447, there are ways for attackers to forge headers on requests; that's when Rails started doing CSRF checks on AJAX POSTs, which it hadn't been doing previously. (CVE-2011-0696 is the same thing for Django.)

On the flip side, the mitigation for that CVE included having Rails apps send the CSRF token with *all* AJAX requests, including GETs, so no changes client-side should be needed in most apps to send the CSRF token. You just have to check it.