Fabian Lange
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
There was another problem that this fix corrected which is data loss when the field that you forget to unset is a m2m list. 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?
I am happy, that this was rolled back.
J. Phililp: You must fix your form. "there is no way to "fix" the problem for the developer"
Is symfony 1.2.8 fully compatible with 5.3 and safe to deploy on production with the last stable PHP version?
@T.Nunes: 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
@Fabian Lange: 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! :)
"As a matter of fact, all frameworks around 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.
@Nate Abele: I suppose you are talking about the "$disabledFields" configuration setting you have in CakePHP. And symfony has the same kind of setting. But I was talking about the fact that you cannot secure your web form "magically" without any intervention of the developer. In symfony or CakePHP for that matter, the developer need to declare the expected fields, or the disabled fields; and it makes sense. Or am I missing some CakePHP magic?
@Fabien: hey, thanks for the clarification. Actually, CakePHP does have just this sort of magic. :-) Since it is assumed that all form fields are generated with the FormHelper, CakePHP is able to keep a log of what fields to expect. When the form ends, the FormHelper generates a hash of the field list (optionally, this hash also calculates the values of any hidden fields, if you do not wish those to be tampered with as well), salted with a CSRF token which is included in the user's session.
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.
hello, 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