Not so much a SecurityException as a pre-defined page redirect to the
naughty page.
On 11/10/05, Ron Piterman <[EMAIL PROTECTED]> wrote:
>
> I could *imagine* that the "right" way would be adding a hivemind
> interceptor to the direct service.
> This should be as easy as contributing anything to hivemind -
>
> <implementation service-id="..." if="*great ah...*">
> <interceptor service-id="..." before="..." after="..." name="..."/>
> </implementation>
>
> now you can add such an interceptor to the direct service - question is
> how to nicely configure it to match direct requests to security rules.
> I guess throuwing a SecurityException will end up in a 500 for the user...
>
> Please tell if you did that - it would be something we still need...
>
> Cheers,
> Ron
>
>
>
>
> ציטוט Patrick Casey:
> >
> >
> > 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]
>
>
