#17120 closed Bug (fixed)
FormSet max_num can be bypassed and any number of forms saved
Reported by: | Miloslav Pojman | Owned by: | nobody |
---|---|---|---|
Component: | Forms | Version: | 1.3 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I've reported this issue to security@… first. It is not considered to be security issue (see Russell's email bellow) so I open it here.
Formsets accept its max_num from data submitted by the user and ignore a value set in the code. It means that user can bypass any formset max_num check and save any number of forms he like.
For example: a user has paid for two persons so I will offer him formsets with max_num=2 in order to make an order. If he tampers the form data he can send orders for any number of persons. In case of model formsets it means that any number of orders will be saved to a database despite the max_num value.
On Fri, Oct 21, 2011 at 2:14 AM, Russell Keith-Magee <russell@…> wrote:
We discussed this issue internally, and decided that it wasn't a security issue. I can certainly see why you raised this as an issue. It's certainly a reasonable assumption that max_num should be interpreted as a limit, and that it shouldn't be able to be tampered with by a user. To that end, it's definitely a bug; we should improve the documentation, and we should make whatever changes we need to make to ensure that max_num is handled server side, rather than relying on the client-provided value. An example that helps explain why this isn't a security issue. Consider the following case: * Page has a form with inlines, and max_num = 3. There is 1 existing inline object. * User 1 loads the edit page * User 2 loads the edit page * User 1 submits a POST containing 3 inlines (1 original plus 2 new entries) * User 2 submits a POST containing 3 inlines (1 original plus 2 new entries, different to those from User 1). In this case, both User1 and User2 have obeyed max_num in their forms, but User 2 will, in practice, violate the max_num rule. This situation exists even when max_num isn't being tampered with; so it highlights that max_num is really just a guidance for dynamic form layout, not a data validation control. If it were a validation condition, it would need to be handled at the model level, not the form level. Thank you very much for raising this as a security issue, and apologies again for the poor feedback on our part. If you raise this as a ticket, we can address the client-side modification issue as a normal bug. Yours, Russ Magee %-)
Change History (3)
comment:1 by , 13 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:3 by , 9 years ago
It might be related/duplicate of #20347 "Add an absolute_max parameter to formset_factory" too.
I think this has been fixed with the introduction of
validate_max
and the fact that if the number of forms in a data set exceedsmax_num
by more than 1000, then the form will fail to validate as ifvalidate_max
was set.