On Mon, 1 Jul 2002, Jing Zhou wrote:
> Date: Mon, 1 Jul 2002 14:41:25 -0500
> From: Jing Zhou <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Security issues with Struts
>
> I believe Struts have provide a basic mechanism to resolve
> the problems associated with the multiple submits. But when
> considering this in a security issue context, we might have rooms
> to enhance the mechanism - here is my little thoughts:
>
> 1) Since the transaction token is visible by client browser, users
> could use the same token to cheat Struts by a client program.
>
A snooper could make the initial submit for a particular form (if they
could get it in faster), but couldn't do much else. However, the security
implications of exposing the session id are *much* more serious than
exposing the transaction token. If data exposure is an issue, use an SSL
connection.
> 2) Even though request scoped form beans plus a transaction
> token make Struts thread safe, but I observed developers still make
> mistakes by assigning attributes from the request scoped form beans
> to their own version of session scoped java objects, which is
> possibly participating in a transaction from the previous request.
> Any non-trivial application have session scoped objects, so this
> is very likely to happen in general.
>
I'm not sure what a framework can do about this in any general way. Do
you have some specific suggestions? I fear that just "single thread all
access to the session" is going to cause more problems than it would
solve.
> 3) The session scoped form bean plus a transaction token may not
> work correctly all the time: Before the first request reach the
> statement isTokenValid(request, true), the second request might
> already corrupt the session scoped form bean by populating bad
> data. Therefore it corrupts the transaction state of the first request,
> if the form bean is participating in that transaction.
>
Session scope form beans are already susceptible to problems of
simultaneous access, even without taking transaction tokens into
consideration. That is why request scope form beans are generally
recommended.
> Here are what I am doing in our own project and hopefully it
> will help Struts:
>
> We created a client transaction context (relative to EJB server)
> which manage both JDBC connection based transaction and JTA
> UserTransaction based transaction. In our own version of the
> RequestProcessor, we detect the transaction context before
> populating the form bean. If an active client transaction context
> found in the HttpSession, there are two choices, let the request
> wait or throw an exception. I prefer the second one, which has a
> consistent semantic with SessionBean defined by EJB 2.0 spec:
> Container will throw exception if there is a concurrent access
> to the business method of the same stateful SessionBean instance.
> In other words, Struts could guard the container in early stage and
> solve the potential problems 1-3, and many bad comments on
> the session scoped form beans will be gone :-)
>
> Is my thoughts valid? Any further thoughts?
>
Many (maybe most?) Struts based apps don't use EJBs. Is there a way we
could define the semantics of this sort of things in terms of APIs that
Struts could support, that don't rely on them?
> Jing
>
Craig
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]>
> Sent: Monday, July 01, 2002 11:54 AM
> Subject: Re: Security issues with Struts
>
>
> > There are at least a couple of issues that I can pull out of your problem
> > description -- here's my thoughts on them.
> >
> > REUSE OF FORM BEANS
> >
> > You only have to worry about reuse of the same physical form bean on
> > multiple requests if you are using session scope to save them in. If you
> > are using request scope (recommended for performance anyway, because it
> > reduces the memory load on the server), a new bean gets created populated,
> > and validated for each request. That still leaves the problem of
> > detecting when the user submits the "same" form twice ...
> >
> > DETECTING MULTIPLE SUBMITS
> >
> > This is a general issue for all web applications, not specific to Struts.
> > However, Struts provides a solution based on the concept of a "transaction
> > token" that can be used to easily detect when the user tries something
> > like this. It works as follows:
> >
> > * In your Action that sets up the input form, call the method:
> >
> > saveToken(request)
> >
> > somewhere along the way, before forwarding to the actual page.
> > This records a serial number in the user's session.
> >
> > * When the <html:form> tag actually renders the form, it sees the
> > serial number and generates a hidden field to include it's value
> > along with the rest of your fields.
> >
> > * In the Action that receives the form (after validation), you can
> > call the method:
> >
> > isTokenValid(request, true);
> >
> > to check the token included in the request (if any), and clear the
> > value saved in the session (which is normally what you want to do).
> > This method will return false if there is no token at all in the
> > form, or if the token doesn't match the saved value. The fact that
> > you are resetting the saved value means that it will also return
> > false if the user submits a form, presses stop, and submits it again.
> >
> > I believe that your session synchronization approach isn't necessary to
> > deal with the particular problem you've described (although it might be
> > useful for other application-specific reasons). I hesitate to add
> > something like this to the framework itself, though -- managing
> > simultaneous requests to the same session has such a wide range of
> > possible impacts that I don't think a single simple solution is going to
> > cover all of the use cases. And using request scope for form beans covers
> > quite a large subset of the possible impacts all by itself (at the cost,
> > of course, of having to include hidden variables on your forms for
> > multi-page form beans).
> >
> > Craig
> >
> >
> >
> > On Mon, 1 Jul 2002, Marcel Kruzel wrote:
> >
> > > Date: Mon, 01 Jul 2002 08:46:11 +0200
> > > From: Marcel Kruzel <[EMAIL PROTECTED]>
> > > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Security issues with Struts
> > >
> > > Hello Struts developers,
> > >
> > > We are now developing an internet banking
> > > application with Stuts of course.
> > > Of course, we are highly concerned
> > > in possible security holes in the framework
> > > (or in the application using the framework).
> > > I believe, there is one, that, when properly
> > > used, can cause some troubles for developers!
> > >
> > > Here it is:
> > >
> > > Imagine a scenario, where user submits a form,
> > > the Struts automatically populate the
> > > form bean and then
> > > the validation of the parameters takes place.
> > > After that, if OK, the perform method is called.
> > > Here, I already know, that the
> > > params were ok, so I write the
> > > transaction to database. The problem here
> > > is the perform method. When precisely at the
> > > moment of perform method call user decides
> > > to submit the form once again (with
> > > different values of course), the form bean
> > > is again populated, and possibly wrong
> > > (not validated) data might be writen to database
> > > (by the first thread, that is not aware
> > > of the second submit).
> > > I am afraid, there is not a possibility to
> > > synchronize acccess to the form,
> > > since the population of form bean is automatic.
> > >
> > > I know, that the solution to the problem here is
> > > in the perform method
> > > to make copy of the parameters and then validate
> > > them again. Or, I can
> > > make validation only in the perform method,
> > > but first I have to remove the
> > > form bean from session, then validate
> > > and then write to database, and then possibly
> > > return that form bean to the session.
> > >
> > > Sorry for so long description,
> > > but I tried to make myself as clear as possible.
> > >
> > > My preferred solution to the problem would be:
> > > In the struts-config.xml put an attribute
> > > to action, describing, that handling
> > > such an action requires session synchronization.
> > > Thus everything, starting from form population
> > > and ending with "return mapping.findForward(...)"
> > > would be synchronized on a session object.
> > > (I do this synchronization on a session
> > > anyway - in each perform method).
> > >
> > > So, what do You think?
> > >
> > > Thanx to all contributors
> > > for such a great framework,
> > > and enjoy the summer.
> > >
> > > Marcel Kruzel
> > > Czech Republic
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
