1. encode user id in the order id you store in the db:
user-id 123 relative order-id 41 stored order-id = 123-41 this way he has no chance to request an order from another user ever, since even he sends 51 to check for order 51 of user 456 the system will look up for 123-51 instead of 456-51. 2. store the user id in the order information and cross check it on retrieving orders: user-id 123 order-id 41, order has a field user-id, where 123 is stored. If user 456 tries to retrieve order 123 the system checks whether the oder.userId matches 456 (which it doesn't, since user 123 ordered it) and throws an exception. 3.4.5.6..... many possibilities :-) regards Leon On 1/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
No, I mean that I am a user and log in as usual. I can see that my orders have id's such as 5, 10 and 42. Now I trick a little bit and send another id, say 41 (which is an order of another user), and without a check the action would show me this order. What's the best way to avoid this situation? Zitat von Leon Rosenberg <[EMAIL PROTECTED]>: > Just to clarify things, do you mean another user sending your > sessionId stored in your cookie to the shop? > > leon > > On 1/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi, > > > > The question I have is not purely specific to Struts, but I expect that > it's a > > common problem for Struts users. Suppose you have a web application which > is a > > shop. You have several users, each of which can have orders, accounting > > details, etc. Now a user logs in and you store the the user object in the > > session. Further, you put a list of orders into a request and forward to a > JSP > > that enables to select an order. When the user selects an order, the id is > > submitted to the action, the corresponding order is put into the request > and > > you forward to the OrderDetails page. > > Up to now, everything is pretty standard. However, what happens if a user > logs > > in, but then submits an arbitrary id - this would enable him to see orders > from > > other users! How can such security lacks be avoided best? > > > > Cheers, > > > > Thorsten > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
