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, uni@(protected):
> 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 <rosenberg.leon@(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, uni@(protected):
> > > 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: user-unsubscribe@(protected)
> > > For additional commands, e-mail: user-help@(protected)
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@(protected)
> > For additional commands, e-mail: user-help@(protected)
> >
> >
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@(protected)
> For additional commands, e-mail: user-help@(protected)
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)