Yes, despite the wishes of our now extinct "senior" engineer I did add a security filter sort of service to our setup. It's really pretty simple, but relies on the user being pre-authenticated, and having a session object available on the server with their basic information...(Permissions/roles data caching is trickier but mostly handled by ehcache and hibernate).
The security filter is a what...Aspect oriented something or other? A closer? A whatchamacallit? Either way the methods on this service always get called before any of the methods on DirectLink/DirectService/etc/etc...(I just looked it up, it's an interceptor...heh ) ...It determines if the method being called (which is associated with a permission) is allowed to be called by the user, if it isn't then they get booted to a naughty screen where they are informed that it's only possible to get there if they were trying to fu$% around with our urls. It then says something ominous about keeping our eye on them... :) This of course is also tied into the SiteMap component that is available at tacos, but not available with the security scheme, which despite all of my excitement about other things I am not excited about supporting in the community at large. (Nor does hibernate/hivemind support sound fun.) Hopefully gabe will add these things in when he's ready. I can give you the code offline if you want, complete with mocked unit tests and all :) (though they use testng which of course makes junit look very silly and sheepish) jesse On 11/9/05, Patrick Casey <[EMAIL PROTECTED]> wrote: > > > I've run into a situation where I can see *a* solution to a > problem, but I was rather hoping somebody else might have a better one. > > > > I have different types of users on my system. Based on their > role, they can do different things. I control access to resources largely > through the gui so that, for example, "users" don't get any of the links > that point towards admin resources. It gets a bit more subtle than that > though as often administrators and users share the exact same DirectLink, > handled by exactly the same handler, they just have different parameters. > > > > Now, in theory, I'm vulnerable to a malicious user who could > gain a user account and then submit synthetic directlinks referencing admin > type resources. Just because my gui didn't render him a link to the > administrator's user record doesn't mean that he can't type one in; it's > just a string of letters and numbers. I can't do security based on link > structure because, as I mentioned, both users and admins often have exactly > the same physical link structure, rather I have to do it based on content. > > > > Right now, I'm considering the brute force approach of funneling > every (and I do mean every) resource request in my system through a security > resolver. I've done it before, but it's always a royal PITA. So I was toying > around with potential alternate approaches. One thing I'm considering is > adding some sort of a generated hashcode to each of my links and then > rejecting any link which doesn't contain the proper code on the way back in > e.g. > > > > If a link would normally look like: > > > > > http://localhost:9090/Corinna/app?service=direct/1/Home/border.$Menu > <http://localhost:9090/Corinna/app?service=direct/1/Home/border.$Menu&sp=Ssh > ard.Shard&sp=0&sp=20&sp=X&sp=T&sp=X&sp=Sid%7C%3D%7CZZCURRENT_SHARDYY&sp=SD&s > p=X&sp=X> > &sp=Sshard.Shard&sp=0&sp=20&sp=X&sp=T&sp=X&sp=Sid%7C%3D%7CZZCURRENT_SHARDYY& > sp=SD&sp=X&sp=X > > > > Change it to look like: > > > > http://localhost:9090/Corinna/app?service=direct/1/Home/border.$Menu > <http://localhost:9090/Corinna/app?service=direct/1/Home/border.$Menu&sp=Ssh > ard.Shard&sp=0&sp=20&sp=X&sp=T&sp=X&sp=Sid%7C%3D%7CZZCURRENT_SHARDYY&sp=SD&s > p=X&sp=X&checkSum=12345> > &sp=Sshard.Shard&sp=0&sp=20&sp=X&sp=T&sp=X&sp=Sid%7C%3D%7CZZCURRENT_SHARDYY& > sp=SD&sp=X&sp=X&checkSum=12345 > > > > Assuming I use a strong, hashing algorithm, and use the session key as part > of the hash along with a private server side key, I should make it > impossible for somebody to spoof one of my links (unless I'm missing > something here, I'm not really a security export). > > > > So my question is: > > > > 1) Has anybody done something like this with link > signing via tapestry? If so, what's a good global approach to ensure that > each and every link is A) signed and B) checked for validity before being > passed down to its appropriate listener function? > > 2) How are other people solving the spoofable link > problem? Is the default check-every-resource request for security access > still the norm? > > 3) Can you see an obvious hole in my proposed > approach (bearing in mind, again, I'm not a good crypto or security guy)? > > > > Any input would be appreciated, > > > > --- Pat > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
