I thought about the redirect_to method when I saw Ryan’s screencast of how to go back with redirect_to :back. That way the user will be redirected to the URL from the Referer header field, it’s the same as redirect_to request.referer. The Referer is a user-supplied value which is set by the browser or another user-agent. It should not be possible to spoof the Referer in an Ajax request, but some browsers seem to allow it (Firefox does not).
An attack on this is quite unlikely. However if the attacker manages to manipulate the Referer, the victim will be redirected to another site. This site may install malicious software on the victim’s computer through browser security holes. Or it could be a phishing site that asks the victim to enter his username and password.
Then I saw comment #11 which suggests to put the referer into a hidden field:
<%= hidden_field_tag :referer, (params[:referer] || request.env[‘HTTP_REFERER’]) %>
The hidden_field_tag method automatically escapes the value, so it is not vulnerable to XSS. However, be aware of XSS if you use the params otherwise.
More important is that you would use redirect_to params[:referer]. This is a very nice redirector for any URL you like. If the attacker sets the params[:referer] value by supplying the parameter to the site with the hidden_field_tag from above, the victim will be redirected to any desired page:
http://www.yourapplication.com/controller/action?referer=http://www.malicious.tld
Header Injection
Then there is a another problem with user-supplied values in the HTTP headers: Header Injection. It seems that Ruby/Rails does not sanitize the parameter passed to redirect_to. That means the user may set any header field he likes:
http://www.yourapplication.com/controller/action?referer=http://www.malicious.tld%0a%0dX-Header:+Hi!
Note that “%0d%0a” is URL-encoded for “\r\n” which is a carriage-return and line-feed in Ruby. So the resulting HTTP header will be:
HTTP/1.1 302 Moved Temporarily
(…)
Location: http://www.malicious.tld
X-Header: Hi!
And even if you allow the user to supply only parts of the target URL, the attacker may still overwrite the Location header field (and thus redirect to any site he wants):
http://www.yourapplication.com/controller/action?referer=path/at/your/app%0aLocation:+http://www.malicious.tld
Response Splitting
As Header Injection is possible, Response Splitting might be, too. In HTTP, the header block is followed by two carriage-return, line-feeds (CRLF) and the actual data (usually HTML). The idea of Response Splitting is to inject two CRLFs, followed by another response with malicious HTML. The response will be:
HTTP/1.1 302 Found [First standard 302 response]Date: Tue, 12 Apr 2005 22:09:07 GMT
Location:
Content-Type: text/html
HTTP/1.1 200 OK [Second New response created by attacker begins]Content-Type: text/html
<html><font color=red>hey</font></html> [Arbitary input by user is shown as the redirected page]Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
Read the original article here. Under certain circumstances this would present the malicious HTML to the user. However, this seems to work with Keep-Alive connections, only (and many browsers are using one-time connections). But you can’t rely on this. In any case this is a serious bug, and you should update your Rails to version 2.0.5 or the soon-to-be-released 2.1.2.
