For sake of completeness, this has been fixed in https://github.com/symfony/symfony/commit/6c67476ef049d52583ececd581cb44f80bca55cf
Cheers, Bernhard -- Bernhard Schussek Blog: http://webmozarts.com Twitter: http://twitter.com/webmozart 2012/11/22 Cameron Junge <cameron.ju...@sella.co.nz> > I really like the idea of specifying the position! The current behaviour > is to take the left-most IP and use that as the current IP: > > $clientIp = explode(',', $this->server->get('HTTP_X_FORWARDED_FOR')); > foreach ($clientIp as $ipAddress) { > > So rather than trust the left-most IP, change it to instead only trust the > IP at position X from the right. This is assuming that your proxy/other > proxies are appending the IP correctly. An empty parameter could mean the > first position on the left (current behaviour....) or the last on the right > (seems safer). > > Much better! > > Cameron > > > On Friday, November 23, 2012 10:36:36 AM UTC+13, Sebastian Krebs wrote: > >> 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/<http://blog.gingerlime.com/2012/rails-ip-spoofing-vulnerabilities-and-protection/> >> Definitely >> worth reading. >> >> >> 2012/11/14 Cameron Junge <camero...@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/**sy**mfony/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 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> >>> >> >> >> >> -- >> 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 > -- 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
