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
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
In that case, when you do not unset the field in the form but you do not have it in the display section of the generator.yml file, Symfony will remove all the existing m2m relations for that record when the form is saved, at least for Doctrine.
Would it be possible to keep the fix for such a case only?
J. Phililp: You must fix your form. "there is no way to "fix" the problem for the developer"
It should, however because 5.3 is new and symfony not tested by the majority of the community against it, there is a chance that there are still bugs. But no major at least. The decision if you want to go for production for it can only be made by you. So I recommend that you set up som test environment and test you application
Thanks for the info.
I'm gonna start another project with symfony using PHP 5.3 from the start.
Let's see how it goes! :)
are vulnerable and have the exact same problem."
Correction: CakePHP is not vulnerable to this issue, nor has it ever been (http://book.cakephp.org/view/257/Configuration). Not only that, but allowing exceptions to the security system is actually quite simple.
Please do a little research before making unfounded claims about other software projects.
When the form is submitted, the Security component compares this hash to the hash that it generates using the POST data, and the user's CSRF token. All this is handled completely transparently, without the user having to redundantly specify the included form fields.
The $disabledFields property I pointed to earlier allows developers to omit certain specific field patterns from the hash calculation on the backend. Allowing, for example, designers to author parts of forms in raw HTML, or front-end developers to generate additional fields with JavaScript. This provides a good default level of security, while allowing for additional flexibility in a safe way.
Anyway, hope that helps clarify things. I'm not terribly familiar with the inner workings of Symfony's forms system, but since you do have a similar notion of tracking form fields, I would think that setup would be feasible for you as well. Not sure about the implications for you guys of crossing rendering context boundaries (i.e. elements/partials, etc). We solve this problem by maintaining the same object instance of the FormHelper.
i'm using symfony 1.2.8 in my project and i don't find any plugin for Feeds and Captcha, i tried to install sfFeed2Plugin and sfCryptoCaptchaPlugin, but it told me that iot's no compatible