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]
