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. 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 > > > > 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>. > > > > 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<javascript:> > > To unsubscribe from this group, send email to > > symfony-devs...@googlegroups.com <javascript:> > > For more options, visit this group at > > 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
