Response Splitting Risk
Posted by michael October 19, 2008 @ 02:03 PM
The Ruby HTTP libraries used by Rails do not perform any santization of the values of their HTTP Headers. This can lead to Response Splitting and Header Injection attacks in certain circumstances where user-provided values are written into response headers. These malformed values can be used to set custom cookies, and forge fake responses to users if your application uses any of the user submitted parameters to construct HTTP headers without sanitizing.
A common scenario where this can be exploited is where your application takes a URL from the query string, and redirects the user to it. To mitigate this common scenario new versions of Rails will be released which sanitize the values passed to redirect_to. However you will still need to take care when writing other values to response headers.
The new versions which will contain the fixes are:
- 2.0.5
- 2.1.2
- 2.2.0
These releases are not available immediately, so in the event that it’s infeasible or inconvenient for your application to sanitize the user-supplied values it passes to redirect_to, patches are available at the following locations.
Users of Edge Rails prior to ba80ff74a962 should update to the latest revisions, cherry pick the change at ba80ff74a962 or or apply this patch
Thanks to Luka Treiber and Mitja Kolsek of ACROS Security for notifying us of this issue and the Ruby Security team for their advice.
Is the restful_authentication plugin affected by this? I would think not, since the redirect only works for actions that exist and need authentication, but still..
Not by default as it stores the request_uri rather than something from params.
I’d like to understand a little bit better how this attack works to be able to judge if my apps are at risk. Is there a site I can go to find out?
The paper’s linked from the wikipedia entries are worth reviewing.
I was using mod_security for Apache and it immediately broke my cookie-based authentication (since mod_security does not allow newlines in cookies, and Rails does).
That would seem to imply that Rails core is not using mod_security, which is a little worrisome…
Meant cookie-based session store…
7pv4nm4om5j1qqzo
n7slg2kmmmchq8f9