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/
> Definitely
> worth reading.
>
>
> 2012/11/14 Cameron Junge <camero...@sella.co.nz <javascript:>>
>
>> 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 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
>>
>
>
>
> --
> 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
