I mentioned Acegi twice as a possible solution, as it certainly is for
Problems 1 and 2, but I also explored why I believe it would not be
adequate for Problem 3.
Jim
-----Original Message-----
From: Ben Wong [mailto:[EMAIL PROTECTED]
Sent: Monday, July 10, 2006 9:49 AM
To: 'Tapestry users'; 'Tapestry users'
Subject: RE: Securing Tapestry Applications
Correct me if I am wrong, but doesn't Acegi solve most, if not all, of
these
problems?
http://acegisecurity.org/
Ben
> -----Original Message-----
> From: Jim Steinberger [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 10, 2006 5:01 AM
> To: Tapestry users
> Subject: Securing Tapestry Applications
>
> Hey all,
>
>
>
> I'm listing just a few security issues and possible solutions below.
> For the benefit of all, by all means challenge my assumptions, and add
> your own problems. But please at least consider my Problem 3 listed
> below, as I'm very curious as to whether someone's found a better
> elegant solution.
>
>
>
>
>
> Problem 1: Protecting pages from being accessed anonymously
>
>
>
> In other words, unless the user is logged in, they should not have
> access to any page other than, most likely, your login-page.
>
>
>
> A common solution is to create an abstract superclass for your pages
> that, in its pageBeginRender listener, redirects to the login page if
> there isn't, for example, a User ASO present.
>
>
>
>
>
> Problem 2: Protecting different pages from different logged-in users
>
>
>
> This is really just a more-specific version of Problem 1, and you
could
> use a more-specific version of the solution: create an abstract
> superclass that subclasses the superclass from Problem 1 that checks
to
> ensure that the user is a specific user.
>
>
>
> This can be hard to maintain, though, especially if your various pages
> can be accessed by various combinations of user-types. E.g. you don't
> want to have to create superclass protection-page for every
combination
> of user-types in your system. Better to, instead, assign a set of
> accesses/permissions to your users, and protecting your pages based on
> the presence/absence of a specific access, which could be assigned to
> multiple user-types.
>
>
>
> You also might consider working something like Acegi security into
your
> system, which can protect a method based on whether a given
> role/permission exists. Google revealed at least one project with
this
> approach: http://www.carmanconsulting.com/tapestry-acegi
>
>
>
>
>
> Problem 3: Protecting the application from logged-in users who are
> spoofing form parameters
>
>
>
> So, you've ensured that the only users accessing your system have
valid
> accounts, and are only accessing the pages and interfaces you've given
> them.
>
>
>
> Well, what if they're malicious, after all, and know how a Tapestry
URL
> works? They see that when selecting an Entity to edit from a list,
that
> the URLs differ like so: "...sp=1...", "...sp=2...", "...sp=5...",
etc.
> Correctly guessing that's the ID of the corresponding Entity, the user
> spoofs the URL to be "...sp=10...". Obviously, they should have
> permission to edit Entities, since they need to be able to edit their
> own Entities, so this page renders correctly. i.e. even with Problems
1
> and 2 solved, there is still the issue of the user being able to
modify
> data for other users.
>
>
>
> We could have our listener method first call an appropriate service
> method that determines, in the example above, whether the logged-in
user
> has permission to edit the given entity.
>
>
>
> However, we don't want to violate the DRY principle: if there are
> multiple places where a given Entity can be selected for editing, we
> would have to add this check in each place.
>
>
>
> Is AOP a solution? Through AOP/Acegi/Spring, you could wrap advice
> around your service methods that has access to the
> currently-logged-in-user. This would be perfect if you were only
> verifying the type of the user, but in this case we're determining
> validity based on the values of the given method-parameters. Most
> service methods will require a different query/method for determining
if
> the user and the given parameters are a "match", so this would
probably
> end up requiring a different Aspect for each method, which doesn't
> really gain us much.
>
>
>
> So ... the best I can come up with at the moment is to pass the User
> object into the service methods that need to be protected, and doing
the
> check inside the method. Persistence layers should perform individual
> units of work, relatively agnostic to what environment it exists in.
> The service layer, however, is for business logic, and it's certainly
> business logic to declare that a user can only edit the Entities that
it
> owns. And since the User object should be a POJO that is not Tapestry
> specific, this doesn't tie the service layer to a particular
> UI-implementation. Further, you're defining this logic in only one
> place, and your compiler will remind you in each corresponding
Tapestry
> listener that a given service method must be made aware of what user
is
> calling it.
>
>
>
> A way to improve on this is probably to inject the user-object into
your
> service object at the object-level instead of the method-level. If
> you're using HiveMind for your services, this is simple enough. It's
> well-documented how to make Spring services available to
> Tapestry/HiveMind - has anyone done the reverse? i.e. made it
possible
> to inject Tapestry ASOs into a Spring service?
>
>
>
> Has anyone tackled this more elegantly than I've described? Perhaps
> with a totally different design approach to security and
> user-separation?
>
>
>
> This problem has other forms ... such as the user tampering with
> serialized objects. This would be an even rarer case than above,
> however, and partially mitigated if we've ensured the user can only
> screw with his/her own information. However, one potential problem
that
> comes to mind with this has to do with transitive persistence (i.e. if
> you're using an ORM like Hibernate, entities attached to the entity
> you're persisting might also be persisted). If for some reason you've
> mapped your entities so that AddressType is persisted when the Address
> it's attached to is persisted, and this is further being serialized in
> the HTML, it could be possible for the user to change that AddressType
> (which could, of course, be associated with thousands of other
> Addresses). Obviously, that example is an anti-pattern that shouldn't
> happen in the first place, but it nonetheless illustrates a couple
areas
> that deserve some critical thinking.
>
>
>
>
>
> Thanks,
>
> Jim
---------------------------------------------------------------------
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]
