Every field, that is submitted from a form is considered as belonging to unit that processes it. This poses a security threat, because field absence on a form doesn't mean, that if added it won't be processed.
For example if attacker founds out what field gives user extra rights on website and just injects it to a form, then this would going to be saved directly to database without any validation at all. Luckily we already have
kDBEventHandler::getRequestProtectedFields method, that allows to define which fields are in no-case allowed to be written from submitted form data into the database.
However I haven't seen anyone using that much, so the problem remains.
Maybe we need to use deny-by-default logic, where none of fields by default isn't allowed to be submitted from a form and developer must explicitly define which fields are allowed. Right now we using same policy with permissions: everything is denied and if developer decides to:
- give user permission, that is bound to an event being executed
- or by other means allows access to an event
then he will be responsible for that. Hopefully developer would think twice before allowing to set forged password reset token, that in theory would allow anyone to reset any other user's password using standard "Forgot Password" form.
Also I've found a video, which explains several form-related security issues and methods, used to solve them in Laravel framework: