Skip to content

[FrameworkBundle] used the new method for trusted proxies #6154

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 15, 2012
Merged

[FrameworkBundle] used the new method for trusted proxies #6154

merged 1 commit into from
Dec 15, 2012

Conversation

bamarni
Copy link
Contributor

@bamarni bamarni commented Nov 29, 2012

This makes the framework bundle using the new method from the request class.

@@ -62,6 +62,9 @@ public function load(array $configs, ContainerBuilder $container)
}
$container->setParameter('kernel.secret', $config['secret']);

$container->setParameter('kernel.trusted_proxies', $config['trusted_proxies']);

// for BC, to be removed in 2.3
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

best would be to use a @deprecated annotation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lsmith77 : you're right, should it be /** @deprecated ... */ (as it's a phpdoc annotation) or is it ok in a standard comment?

@fabpot
Copy link
Member

fabpot commented Dec 5, 2012

As this is a sensitive issue, can you add some tests? Thanks.

@@ -62,6 +62,9 @@ public function load(array $configs, ContainerBuilder $container)
}
$container->setParameter('kernel.secret', $config['secret']);

$container->setParameter('kernel.trusted_proxies', $config['trusted_proxies']);

// @deprecated, to be removed in 2.3
$container->setParameter('kernel.trust_proxy_headers', $config['trust_proxy_headers']);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't an exception be thrown instead as this is related to security ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no security issue when using this configuration setting. The only thing is that it is not as flexible as the new way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be a security vulnerability if the webserver socket access isn't restricted to the proxy IP, as any client would then be able to fake a client IP, wasn't this case the reason of the method change?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand your last message, but there are no security issues. When calling trustProxyData(), we now just assume that are trusting the last proxy, and as such we return the last value of the x-forwarded-for header.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example if one read the cookbook entry about varnish and decides to
install it, he will typically end up with apache listening to port 8080
for eg. and varnish to 80. But if he didn't put any concern about
security at system level, apache socket could be publicly accessible,
thus making any client being able to fake user's IP by requesting
"host:8080" with the forwarded-for header, this wouldn't be possible
with the new method.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you talking about sockets here? I don't get it. But anyways, the old method is safe as this is just a shortcut for setTrustedProxies(array($request->server->get('REMOTE_ADDR')).

@bamarni
Copy link
Contributor Author

bamarni commented Dec 6, 2012

Well I don't know why it fails on travis, I can't run the full test suite locally because of a segfault but phpunit src/Symfony/Bundle/ marks all the tests as passing.

@fabpot
Copy link
Member

fabpot commented Dec 6, 2012

But it looks like the failing tests come from what you've changed.

@bamarni
Copy link
Contributor Author

bamarni commented Dec 6, 2012

Yes, I'm not saying it's not my fault but I can't reproduce this as locally it tells me they pass, I'll try to fix this this evening.

@bamarni
Copy link
Contributor Author

bamarni commented Dec 6, 2012

Apparently it fails only when running the whole testsuite, looking at other travis builds I can see this one on 2.0 : https://travis-ci.org/symfony/symfony/jobs/3495511 which fails in a similar way than here (https://travis-ci.org/symfony/symfony/jobs/3530928). Because of a place trying to access an undefined $_SERVER key : PHP Notice: Undefined index: SCRIPT_NAME ... but I can't find where, and the stack trace references some phpunit classes.

I'd be happy if someone could give me some pointers in here as I don't have any clue about how to fix this..

@bamarni
Copy link
Contributor Author

bamarni commented Dec 6, 2012

As a consulsion I'd say I can't run the whole testsuite locally (it fails even when I revert my commit), so there is no reliable way for me to fix this, if anyone is up for continuing this feel free.

@fabpot
Copy link
Member

fabpot commented Dec 11, 2012

@bamarni Can you just update this PR with the code change and no tests at all? I will then finish the PR. Thanks.

@bamarni
Copy link
Contributor Author

bamarni commented Dec 11, 2012

@fabpot: thanks for helping me out on this, hope you won't run into the same issue!

[FrameworkBundle] Added tests for trusted_proxies configuration.
@fabpot fabpot merged commit f0743b1 into symfony:2.0 Dec 15, 2012
fabpot added a commit that referenced this pull request Dec 15, 2012
This PR was merged into the 2.0 branch.

Commits
-------

f0743b1 Merge pull request #1 from pylebecq/2.0
555e777 [FrameworkBundle] Added tests for trusted_proxies configuration.
a0e2391 [FrameworkBundle] used the new method for trusted proxies

Discussion
----------

[FrameworkBundle] used the new method for trusted proxies

This makes the framework bundle using the new method from the request class.

---------------------------------------------------------------------------

by fabpot at 2012-12-05T10:38:20Z

As this is a sensitive issue, can you add some tests? Thanks.

---------------------------------------------------------------------------

by bamarni at 2012-12-06T13:00:24Z

Well I don't know why it fails on travis, I can't run the full test suite locally because of a segfault but ```phpunit src/Symfony/Bundle/``` marks all the tests as passing.

---------------------------------------------------------------------------

by fabpot at 2012-12-06T13:08:11Z

But it looks like the failing tests come from what you've changed.

---------------------------------------------------------------------------

by bamarni at 2012-12-06T13:29:33Z

Yes, I'm not saying it's not my fault but I can't reproduce this as locally it tells me they pass, I'll try to fix this this evening.

---------------------------------------------------------------------------

by bamarni at 2012-12-06T17:49:28Z

Apparently it fails only when running the whole testsuite, looking at other travis builds I can see this one on 2.0 : https://travis-ci.org/symfony/symfony/jobs/3495511 which fails in a similar way than here (https://travis-ci.org/symfony/symfony/jobs/3530928). Because of a place trying to access an undefined $_SERVER key : ```PHP Notice:  Undefined index: SCRIPT_NAME ...``` but I can't find where, and the stack trace references some phpunit classes.

I'd be happy if someone could give me some pointers in here as I don't have any clue about how to fix this..

---------------------------------------------------------------------------

by bamarni at 2012-12-06T18:00:57Z

As a consulsion I'd say I can't run the whole testsuite locally (it fails even when I revert my commit), so there is no reliable way for me to fix this, if anyone is up for continuing this feel free.

---------------------------------------------------------------------------

by fabpot at 2012-12-11T09:47:48Z

@bamarni Can you just update this PR with the code change and no tests at all? I will then finish the PR. Thanks.

---------------------------------------------------------------------------

by bamarni at 2012-12-11T16:58:17Z

@fabpot: thanks for helping me out on this, hope you won't run into the same issue!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants