On Thu, 4 Jul 2002, Phil Steitz wrote:
> Date: Thu, 4 Jul 2002 01:20:04 -0400
> From: Phil Steitz <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Security issues with Struts
>
> IMHO, Struts already provides a solid framework for developing
> thread-safe, secure web apps. At the end of the day, developers need to
> understand and adhere to basic security and concurrency best practices.
Agreed.
> I can, however, offer one idea that is essentially an extension to the
> J2EE spec:
>
> Struts apps running under 2.3-compliant containers (e.g. Tomcat 4) can
> use J2EE container-managed security to protect URIs. However, the spec
> only provides support for role-based access control. Most real apps
> require method+data-level authorization control, leaving us to develop
> external "authorization services" or application-based security of some
> kind.
If you are using EJBs, J2EE container managed security gives you method
level control, based on the same set of roles that is returned when the
web container authenticates a user. For data level control, apps are
still on their own.
In either EJBs or servlet/JSP, you can also make programmatic decisions
based on the roles possessed by the current user -- in Struts apps, you
will typically see the request.isUserInRole() method utilized for this
purpose. There are even quite a few tags that use this, so you can (for
example) show certain portions of the page only to authorized folks:
<logic:present role="manager">
... menu options only a manager can execute ...
</logic:present>
The implementation of this calls isUserInRole() under the covers.
> What would be interesting to add to Struts would be
> container+framework-managed method+data access control for Actions.
> What I have in mind here is something like the following. Extend the
> Realm concept to carry along a list of user attributes to be used for
> Action authorization. These could just be the all the columns other
> than userCred and userName in the userTable in a JDBC Realm, for
> example. Then support "authProperty" and "realmProperty" attributes in
> Action declarations that force a check of form bean data against user
> attributes in the Realm data source before the action is invoked. For
> example, the Action declaration,
>
> <action path="/transferFunds"
> type="com.big.bank.MoveMoneyAction"
> name="transferForm"
> authProperty="accountNumber"
> realmProperty="acct_num"
> scope="request"
> input="/transfer.jsp"/>
>
> would force the accountNumber property of the transferForm to be checked
> against the "acct_num" in the Realm data source before
> MoveMoneyAction.perform() is invoked.
>
Wouldn't that also require defining what a Realm is and how it works (i.e.
something like Tomcat's version of a Realm)? That seems pretty ambitious
for a framework -- especially one where I try to encourage people to use
standard container managed security facilities instead of rolling your
own.
> To handle the more general case in which the realmProperty is a list
> (e.g. a list of several accounts associated with a principal), a more
> complex setup would be required, but the basic idea of checking form
> bean fields against user properties still applies.
>
If anybody is going to do this kind of thing it should really be the J2EE
container, not an app framework, so that everybody can take advantage of
it. There are already efforts to standardize the authorization part of
the equation (JSR-115), and starting to be efforts on the authentication
side as well (including things like JAAS and Project Liberty).
> I am a Struts newbie with experience limited to 1.0, so the ideas above
> may not be expressed in the best "Struts way"; but I think that the
> basic concept deserves consideration. Apologies if this has already
> been considered and rejected. I didn't see much in the archives on
> authorization...
>
In 1.1, you can define <action>s with a role element defining the role(s)
that are required before this action can be executed. Of course, you can
accomplish the same thing with standard web.xml security constraints, by
adding a URL pattern for each action URL you want to protect.
Craig
>
> Craig R. McClanahan wrote:
>
> >
> >
> > 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] >
> >
>
>
>
> --
> 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]>
