You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Patrick Casey <pa...@adelphia.net> on 2005/11/10 03:51:27 UTC
Controlling Access to Resources
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
Re: Controlling Access to Resources
Posted by Jesse Kuhnert <jk...@gmail.com>.
Not so much a SecurityException as a pre-defined page redirect to the
naughty page.
On 11/10/05, Ron Piterman <rp...@gmx.net> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: Controlling Access to Resources
Posted by Ron Piterman <rp...@gmx.net>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Controlling Access to Resources
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <pa...@adelphia.net> 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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Controlling Access to Resources
Posted by Patrick Casey <pa...@adelphia.net>.
Yah, I know I could use pageValidate for everything, but that's sort
of bodgy because it's really meant to validate, well, pages, not resources.
So if both users and administrators can see the "change Password" page, it's
awkward to recode it as "users can see the change Password page if and only
if the target resource is *their own* user record, while administrators can
always see if".
Fortunately all my pages use the same resource descriptor so I can
pass that from the validator to my resource manager and determine security
authorization that way, so it will work.
I was hoping to avoid going down that road though because it
basically required I replicate the same logical information twice. I first
secure resources in the gui so that you only see links to things you're
allowed to see. I then secure resources in the resource manager so there's a
duplication of labour I'd like to avoid, hence my flirtation with the URL
signing concept.
--- Pat
> -----Original Message-----
> From: Chris Chiappone [mailto:chiappone@gmail.com]
> Sent: Thursday, November 10, 2005 7:06 AM
> To: Tapestry users
> Subject: Re: Controlling Access to Resources
>
> Tap 4 can be done the same with pageValidate.
>
> On 11/10/05, Damian Krzeminski <da...@pingtel.com> wrote:
> > Patrick Casey wrote:
> > >
> > >
> > > <snip>
> > > 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.
> > >
> >
> > In Tapestry 3.0 (not sure about 4.x) pageValidate is called by
> DirectService (which is used to
> > implement DirectLinks), so if you have authorization code there, your
> direct links might be made
> > inaccessible to less privileged users. If you have "border-like"
> component that is used by all your
> > pages you use its pageValidate to implement simple role based
> authentication.
> > Damian
> >
> >
> > >
> > >
> > > <snip>
> > >
> > > --- Pat
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> --
> ~chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Controlling Access to Resources
Posted by Chris Chiappone <ch...@gmail.com>.
Tap 4 can be done the same with pageValidate.
On 11/10/05, Damian Krzeminski <da...@pingtel.com> wrote:
> Patrick Casey wrote:
> >
> >
> > <snip>
> > 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.
> >
>
> In Tapestry 3.0 (not sure about 4.x) pageValidate is called by DirectService (which is used to
> implement DirectLinks), so if you have authorization code there, your direct links might be made
> inaccessible to less privileged users. If you have "border-like" component that is used by all your
> pages you use its pageValidate to implement simple role based authentication.
> Damian
>
>
> >
> >
> > <snip>
> >
> > --- Pat
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
~chris
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Controlling Access to Resources
Posted by Damian Krzeminski <da...@pingtel.com>.
Patrick Casey wrote:
>
>
> <snip>
> 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.
>
In Tapestry 3.0 (not sure about 4.x) pageValidate is called by DirectService (which is used to
implement DirectLinks), so if you have authorization code there, your direct links might be made
inaccessible to less privileged users. If you have "border-like" component that is used by all your
pages you use its pageValidate to implement simple role based authentication.
Damian
>
>
> <snip>
>
> --- Pat
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org