FormSet max_num can be bypassed and any number of forms saved
|Reported by:||mila||Owned by:||nobody|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
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 %-)