Opened 13 years ago

Closed 12 years ago

#3145 closed defect (invalid)

edit_inline Manipulator processor allows "stealing" of related objects

Reported by: jag@… Owned by: nobody
Component: Core (Other) Version:
Severity: normal Keywords: security
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no


This may be the desired behavior, but I'd probably consider it a security bug. I'll let you decide, and if you agree, I'll come up with a patch for it...

Let's say I have a shopping cart system. So I have two models:

 class ShoppingCart(models.Model):
   # ... snip ...
 class ShoppingCartItem(models.Model):
   shoppingcart = models.ForeignKey(ShoppingCart, edit_inline=models.STACKED)
   product = models.ForeignKey(Product, core=True)
   quantity = models.IntegerField()
   # ... snip ...

Then I have a view using django.views.generic.create_update.update_object and a template that contains:

 <form action="." method="post">
  <input type="text" name="" value="3" />
  <input type="text" name="shoppingcartitem.0.product" value="3" />
  <input type="text" name="shoppingcartitem.0.quantity" value="3" />
  <input type="submit" />

If Alice creates a shopping cart with one item, 3 "Product 3"'s as above, and then Mallory comes in to her own shopping cart (not actually accessing the same ShoppingCart object as Alice but a distinct on of her own) and posts to this view with the values:, the item will be removed from Alice's cart and placed into Mallory's cart with a quantity of 100.

I would expect that Django would beef about either a) letting Mallory reassign the ForeignKey value for ShoppingCartItem(pk=3) or b) letting Mallory alter the value of ShoppingCartItem's not related to the ShoppingCart object she's viewing. Neither occurs.



Change History (4)

comment:1 Changed 12 years ago by Gary Wilson <gary.wilson@…>

Triage Stage: UnreviewedAccepted

seems like a nasty bug to me.

comment:2 Changed 12 years ago by Fast exchanger

Cc: None added
Component: Core frameworkDocumentation
Keywords: None added
Owner: changed from Adrian Holovaty to Jacob
Summary: edit_inline Manipulator processor allows "stealing" of related objectsFast exchanger
Triage Stage: AcceptedReady for checkin
Version: unicode

Cool website! Your web site is helpful, All the best!

comment:3 Changed 12 years ago by Chris Beaven

Cc: None removed
Component: DocumentationCore framework
Keywords: security added; None removed
Needs tests: set
Owner: changed from Jacob to Adrian Holovaty
Summary: Fast exchangeredit_inline Manipulator processor allows "stealing" of related objects
Triage Stage: Ready for checkinAccepted
Version: unicode

comment:4 Changed 12 years ago by James Bennett

Resolution: invalid
Status: newclosed

A foreign key is just a foreign key; it has no inherent "meaning". If the Bar model has a foreign key to Foo, that could mean "User A owns this instance and changing it is a security breach", but it could also mean "User A is working with this instance right now but User B can take it over" or it could "mean" something else entirely. It's up to you -- the developer of your specific application -- to decide what the foreign key "means" and implement the appropriate logic.

Note: See TracTickets for help on using tickets.
Back to Top