-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[DoctrineBridge][Security][Validator] do not validate empty values #23341
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
Conversation
Very nice, but what about UniqueEntityValidator? If the |
Will the |
@xabbuh Make a form with an entity as |
Thank you @xabbuh. |
…y values (xabbuh) This PR was merged into the 2.7 branch. Discussion ---------- [DoctrineBridge][Security][Validator] do not validate empty values | Q | A | ------------- | --- | Branch? | 2.7 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #23319 | License | MIT | Doc PR | Nearly all validators operating on scalar values (except for some special constraints) do ignore empty values. If you want to forbid them, you have to use the `NotBlank` constraint instead. Commits ------- fd7ad23 do not validate empty values
@@ -39,6 +39,10 @@ public function validate($password, Constraint $constraint) | |||
throw new UnexpectedTypeException($constraint, __NAMESPACE__.'\UserPassword'); | |||
} | |||
|
|||
if (null === $password || '' === $password) { | |||
return; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change breaks FOSUserBundle's current_password
field used in ChangePasswordFormType
and ProfileFormType
allowing to send empty passwords instead of the user's current one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well they would receive an exception, so I am not sure that is a proper way of handling the case anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used to get the proper constraint message rendered with the form, no exception.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably because you ran it on PHP lower than 5.6, before function hash_equals was used. If that gets a null in comparison, it breaks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here to be specfic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, you are right, 2.8 is the first version that uses hash_equals
. Not sure how this should be resolved though. Should not you use NotBlank
validator anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well this change only standardizes the usage of the validator, since it already ignored empty strings. It is pretty obvious a null
cannot be a password, so I would simply do a fix on the side of FOSUB
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now if using FOSUserBundle's ChangePasswordFormType, then logged in users can change their own password without typing the current password. I created a pull request:
FriendsOfSymfony/FOSUserBundle#2582
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR really shouldn't have been merged as-is in older branches due to this BC break.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still believe that this is an implementation error on FOS side, not a BC break. Empty values should be checked by a specific validator, not by one which by default should not handle them (as I have said before, a null
can not be a password).
This is quite a dangerous change: when you validate a users current password and you do not specify a |
The type is called I don't agree about "at least a big fat warning", I would consider this a security problem and would prefer a revert at least on the UserPassword validator related lines. |
@beberlei Indeed. The more I think about this the more I consider this a serious security problem. |
see #23507 |
This PR was merged into the 2.7 branch. Discussion ---------- [Security] validate empty passwords again | Q | A | ------------- | --- | Branch? | 2.7 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #23341 (comment) | License | MIT | Doc PR | It looks like this part of #23341 causes serious security issues for some users who rely on the validator to also compare the empty string with their user's password (see for example #23341 (comment)). Thus I suggest to revert this part of #23341. Commits ------- 878198c [Security] validate empty passwords again
This PR was merged into the 2.7 branch. Discussion ---------- [Security] validate empty passwords again | Q | A | ------------- | --- | Branch? | 2.7 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | symfony/symfony#23341 (comment) | License | MIT | Doc PR | It looks like this part of #23341 causes serious security issues for some users who rely on the validator to also compare the empty string with their user's password (see for example symfony/symfony#23341 (comment)). Thus I suggest to revert this part of #23341. Commits ------- 878198cefa [Security] validate empty passwords again
This PR was merged into the 2.7 branch. Discussion ---------- [Security] validate empty passwords again | Q | A | ------------- | --- | Branch? | 2.7 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | symfony/symfony#23341 (comment) | License | MIT | Doc PR | It looks like this part of #23341 causes serious security issues for some users who rely on the validator to also compare the empty string with their user's password (see for example symfony/symfony#23341 (comment)). Thus I suggest to revert this part of #23341. Commits ------- 878198cefa [Security] validate empty passwords again
It would be nice to have the option to validate or not validate on empty data, leaving it to the developer. For example, |
Feel free to open an issue and such a feature could be discussed. |
This line https://github.com/symfony/security-core/blob/master/Validator/Constraints/UserPasswordValidator.php#L43 takes out the freedom unlike other constraints where I would have added a |
Nearly all validators operating on scalar values (except for some special constraints) do ignore empty values. If you want to forbid them, you have to use the
NotBlank
constraint instead.