This project is archived and is in readonly mode.
request.remote_ip/X-Forwarded-For may not be an IP
Reported by banditj | February 16th, 2011 @ 02:41 AM | in 3.0.6
hi,
X-Forwarded-For headerfield isn't sanatized if the request comes from a class c network.
i made a poc screencast that shows the bug with the latest rails version with devise and shows more possible attacks
http://webservsec.blogspot.com/2011/02/ruby-on-rails-vulnerability....
quick-fix for internal web-apps:
check request.remote_ip before you use it
best regards
J
Comments and changes to this ticket
-
Michael Koziarski February 16th, 2011 @ 10:22 PM
- Milestone set to 3.0.5
- Importance changed from to Low
The attack vectors they're talking about there assume no one does any sanitization. SQL Injection, shell script exploits etc only apply if people don't check those inputs.
There's certainly a bug here, but it's not a security bug.
-
Michael Koziarski February 16th, 2011 @ 10:29 PM
- Title changed from rails security bug - request.remote_ip/X-Forwarded-For not sanitized to request.remote_ip/X-Forwarded-For may not be an IP
-
Santiago Pastorino February 27th, 2011 @ 03:15 AM
- Milestone changed from 3.0.5 to 3.0.6
-
Christopher Meiklejohn March 3rd, 2011 @ 04:23 AM
Is the issue here just that the input isn't validated as an actual IP address?
-
alindeman March 26th, 2011 @ 03:19 PM
I'd be happy to help fix this, but there are a existing few tests that make me wonder what the expected behavior is:
request = stub_request 'HTTP_X_FORWARDED_FOR' => 'unknown,192.168.0.1' assert_equal 'unknown', request.remote_ip
As the tests are written, it seems like returning a string (non-IP) was thought about. What's the expected behavior here then?
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>