symfony 1.2.8 - rolling back our security fix
Reverting the security fix from 1.2.7
Fabien did revert the fix for the non-visible form fields in Changeset 19819. Here the reasoning from the commit comment:
These changes have been done to plug a security hole in the symfony admin generator (more information on the [symfony blog]( http://www.symfony-project.org/blog/2009/04/27/symfony-1-2-6-security-fix)). But a lot of people complained because it causes more harm than good. The fix disables for instance the possibility to have custom partials. Moreover, the problem also exists in a normal form if you don't use the "echo $form" construct and if you forget to display some non-required fields in the template. After some discussion with the core team members, it appears that there is no way to "fix" the problem for the developer. We thought that we would be able to provide something, but the reality is that we cannot. Is it a problem? We think it is not a big problem as the circumstances under which there can be an exploit are extremely rare or even inexistent as if you are vulnerable, it also means that your database data will be corrupted in some way (read the next section for more information). As a matter of fact, all frameworks around are vulnerable and have the exact same problem. We already provide more advanced security features for the form framework than any other framework around, but we cannot go any further. Security is also a developer matter, and too much magic is sometimes a bad thing. Here is the exact circumstances under which you might be vulnerable: A field is vulnerable only if you forget to display its widget in the template and only if it has a non-required validator. Then, an attacker could potentially inject a valid value for this field, and it will be saved with the rest of the object. But two things greatly mitigate the issue: first, if you forget to display a field, each time you save the form, its value will be lost. So, most of the time, you will be aware of the problem because the data in the database will be corrupted. Second, the attacker need to know the exact field name, which is not easy as no information is contained in the HTML.
I am sorry for any inconvenience this caused, but we felt it was right to revert something which is a wrong solution, even (or especially) when it was a security fix.
Whats else in 1.2.8
We bumped Doctrine to 1.0.10 and fixed some issues with it alongside. We also put some efforts in to ensure PHP 5.3 compatibility and improved some PHPdoc, which were mainly contributions from 1day1ticket. Besides that a lot smaller issues got resolved, so I heavily recommend checking out the changelog.
How to install
Please upgrade your existing projects by updating the reference to the 1.2.8 subversion tag or by running the PEAR upgrade command:
$ pear upgrade symfony/symfony-1.2.8
If you use the 1.2 branch from our SVN repository, just run the
svn update command to upgrade your project.
Last but not least, don't forget to clear your cache by running for doctrine:
$ php symfony doctrine:build-model $ php symfony doctrine:build-forms $ php symfony doctrine:build-filters $ php symfony cache:clear
or when using propel:
$ php symfony propel:build-model $ php symfony propel:build-forms $ php symfony propel:build-filters $ php symfony cache:clear
symfony 1.2.8 - rolling back our security fix symfony.com/blog/symfony-1-2-8-rolling-back-our-security-fixTweet this
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.