Hi, because this "problem" doesn't simply disappear, because nobody is talking about and because there is a follow-up article, that addresses this issues [1] , I have a suggestion
[1] http://blog.gingerlime.com/2012/rails-ip-spoofing-vulnerabilities-and-protection/ Definitely worth reading. 2012/11/14 Cameron Junge <cameron.ju...@sella.co.nz> > While not a vulnerability, per se, it is something that all web developers > (PHP or otherwise) should be aware of. > > The summary is: The x-forwarded-for header should NEVER be trusted. > I wouldn't say never, but never _blindly_. The Request-class already provides a method "trustProxyData()", that tells it to trust the proxies, but I guess (I didn't looked at it yet) it tells the Proxy class to trust _all_ proxies in the chain. So why not simply add an optional parameter to tell, which one (how many) to trust. Request::trustProxyData(2); This should mean, that 2 proxies are in place and there the second last entry in X-Forwarded-For is the last trustable one. As far as I can see it uses the last entry right now, which is wrong, when more then one proxy is used (but at least it's not critical from security point-of-view). I said "optional parameter", because omitting should be the same as Request::trustProxyData(1); what is the current behaviour. Just an idea. What do you think? Regards, Sebastian > > If your app uses IPs for security (ie. ACLS) and you trust your proxy, > then the header can be supplied upstream of your proxy, and your proxy will > append the connection IP it has. > > So, if your proxy has a connection from 10.10.10.10, the browser can > supply a header that is x-forwarded-for of 127.0.0.1. if the header is > trusted, as far as your app is concerned the browser is sitting on > 127.0.0.1, not 10.10.10.10. > > Maybe this could be spelt a little more clearly in the docs? It's a > security risk in that the implications aren't very easy to figure out. > Trusting your proxy is vastly different from trusting a header that can be > set anywhere. > > Cameron > > > > > On Wednesday, November 14, 2012 3:35:13 AM UTC+13, Fabien Potencier wrote: > >> It's not a vulnerability. You need to call the trsutProxy() method only >> when you have a trusted reverse proxy in front of your website (like >> Varnish for instance). >> >> Fabien >> >> -- >> Fabien Potencier >> Sensio CEO - Symfony lead developer >> sensiolabs.com | symfony.com | fabien.potencier.org >> Tél: +33 1 40 99 80 80 >> >> On 11/13/12 3:29 PM, Sam Mateosian wrote: >> > Take a look at this blog post: >> > >> > http://blog.ircmaxell.com/**2012/11/anatomy-of-attack-how-** >> i-hacked.html<http://blog.ircmaxell.com/2012/11/anatomy-of-attack-how-i-hacked.html> >> > >> > Quoting the author (near the end): >> > >> > "Check out Symfony2's Request class >> > <https://github.com/symfony/**symfony/blob/master/src/** >> Symfony/Component/**HttpFoundation/Request.php#**L589<https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundation/Request.php#L589>>. >> >> > On the surface it looks great. Until you notice that it uses a static >> > variable to determine if it should use the proxy information. That >> means >> > that if ANY part of your application wants proxy information (such as a >> > logging class), all of your application after that will get the proxied >> > information. So to see if you're vulnerable to this style attack, grep >> > your code for /$request->trustProxy()/. Also note that there's no >> > in-built mechanism to untrust the proxy. Once it switches to true, it >> > will stay true. Sounds like a major design flaw to me..." >> > >> > Anyone want to take a look? >> > >> > -- >> > If you want to report a vulnerability issue on symfony, please send it >> > to security at symfony-project.com >> > >> > You received this message because you are subscribed to the Google >> > Groups "symfony developers" group. >> > To post to this group, send email to symfon...@googlegroups.com >> > To unsubscribe from this group, send email to >> > symfony-devs...@**googlegroups.com >> > For more options, visit this group at >> > http://groups.google.com/**group/symfony-devs?hl=en<http://groups.google.com/group/symfony-devs?hl=en> >> >> -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- github.com/KingCrunch -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
