Symfony 2.0.24, 2.1.12, 2.2.5, and 2.3.3 have just been released and they contain security fixes for the Validator component (CVE-2013-4751) and the HttpFoundation component (CVE-2013-4752).
Even if Symfony 2.0 and 2.1 are out of maintenance, we are still releasing new versions according to our recent release policy changes.
You can check if your project is up-to-date with the latest security patches by using the SensioLabs Security Advisories Checker.
CVE-2013-4751: Validation metadata serialization and loss of information
Affected versions
All 2.0.X, 2.1.X, 2.2.X, and 2.3.X versions of the Validator component are affected by this issue.
Description
When using the Validator component, if
Symfony is enabled (or any
other cache implementing
Symfony), some
information is lost during serialization (the collectionCascaded and the
collectionCascadedDeeply fields).
As a consequence, arrays or traversable objects stored in fields using the
@Valid constraint are not traversed by the validator as soon as the
validator configuration is loaded from the cache.
Resolution
The patch resolves this issue by adding the missing fields to the serialization mechanism.
You need to upgrade Symfony to its latest version, according to the branch you are using for your project, or you can apply the following patch:
Credits
I would like to thank Alexandre Salome for reporting this security issue and providing a patch, and Bernhard Schussek for reviewing the patch.
CVE-2013-4752: Request::getHost() poisoning
Affected versions
All 2.0.X, 2.1.X, 2.2.X, and 2.3.X versions of the HttpFoundation component are affected by this issue.
Description
As the $_SERVER['HOST'] content is an input coming from the user, it can
be manipulated and cannot be trusted. In the recent months, a lot of different
attacks have been discovered relying on inconsistencies between the handling
of the Host header by various software (web servers, reverse proxies, web
frameworks, ...). Basically, everytime the framework is generating an absolute
URL (when sending an email to reset a password for instance), the host might
have been manipulated by an attacker. And depending on the configuration of
your web server, the Symfony Request::getHost() method might be vulnerable
to some of these attacks.
As these attacks depend on the web server configuration, the fact that you are using a reverse proxy or not, and many other factors, I recommend you to read more about this problem that affects frameworks in all languages, in the great and detailed blog post, Practical HTTP Host header attacks. This article also contains a lot of tips about how to configure your web server in a more secure way.
Resolution
In the past, we did some changes to the Request::getHost() method to
mitigate some of these problems (see PR 6209) by limiting the
allowed characters in a Host, but as it is mostly always the case in such
situations, configuring a set of trusted hosts is the only way to be sure that
your website is secure. That's especially the case for web frameworks as we
cannot dictate a specific configuration for the web server and the reverse
proxies our users are using.
The Symfony releases published today introduce a way to explicitely whitelist
the hosts that your application can respond to. You can configure the whitelist in your
front controllers via the new Request::setTrustedHosts() method:
1 2
// declare a list of trusted host patterns.
Request::setTrustedHosts(array('.*\.?trusted.com$'));or you can also configure it as a setting in your framework configuration via
the new trusted_hosts option:
1 2
framework:
trusted_hosts: ['.*\.?trusted.com$']As this whitelist is optional, it's up to you to check your web server configuration to ensure that you are not vulnerable, or a better option is to configure a list of truted hosts.
You need to upgrade Symfony to its latest version, according to the branch you are using for your project, or you can apply the following patch:
As the patches introduce a new parameter, you need to remove the cache manually after upgrading.
Credits
I would like to thank Jordan Alliot for reporting this security issue and Jean-François Simon for working on the patch.
Thanks for the update!
I think that the regular expression in trusted_hosts be updated to: ^(.*.)?trusted.com$
This way a URL like malicioussitetrusted.com doesn't match the regular expressions, but subdomains like www.trusted.com and other.trusted.com will.
Doesn't the regular expression need a \ before the . in .com ? => '.*.?trusted.com$'
still anyeviltrusted.com is allowed so (^|.)trusted.com$ or (?:^|.)trusted.com$ should be correct
In order to avoid Request::getHost() poisoning, why don't use $_SERVER['SERVER_NAME'] instead of $_SERVER['HOST']? SERVER_NAME is not coming from the client but from the web server.
No tag for the 2.0 and the 2.1 branches ?
Loic: 2.0.24, 2.1.12