Re: Verifying integrity of URLs

[Mark McLaren <m_...@hotmail.com>]

This is an excellent idea!

I hate having to verify the user's request in each action.  Whenever you get 
a request to add, edit or delete something you have to check that the user 
actually owns the 'something'.  Usually this is done by modifying the SQL 
statement when updating the database.  This is painful enough, but sometimes 
you have to write whole extra statements and check the result just to verify 
the HTTP request.  Yuk.

It would be great if struts could be configured to encrypt the URL so we can 
trust the request.  This goes for html form elements too. I think the 
performance hit would be more than compensated for by eliminating unneeded 
database calls. (Even if it's not, it would still free up a lot of developer 
time.)

Has anyone looked at doing this?  Is the plugin architecture flexible enough 
to encrypt the output of the struts-html tags?


Thanks

Mark

(p.s. apologies if others have already posted similar comments - Ross's is 
the only email on this topic I'm aware of)


From: Ross Sargant
Subject: Verifying integrity of URLs
Date: Mon, 01 Sep 2003 22:00:54 +0000

--------------------------------------------------------------------------------

Hi,
    This may be a little off topic, but I thought I'd ask what the experts 
thought.
Many actions often take URL parameters. For example a catalog system's 
"viewItem"
action might include an id number for the
item you wish to view. The action uses this ID to pull something out of your 
RDBMS
(ideally through a service interface), sets a request attribute and then 
forwards to a
JSP to show the relevant data.

Now imagine the case where there are complex rules governing who should be 
able to
view what items. Say for example that a certain user can only view one 
category of
items (which would obviously be enforced by the search interface-you would 
never
generate a link to something they weren't supposed to see in your search 
results).

What is the best way in general to ensure that the user is not playing 
around with url
parameters (in this example by manipulating the id parameter) to get at 
things they
shouldn't. Assume for the moment that the RDBMS cannot help you solve the 
problem.I
don't really see how Roles help here because my understanding of Roles is 
that they
only enable and restrict actions.

One option is to include the security validation in the ViewItem action 
itself so it
will not just blindly display whatever object the parameters referred 
to.This seems
like a problem that might occur in numerous different places though which 
means it
might be benificial to have something more generic.

My other thought was to append a URL parameter that is basically a digital 
signature
of the entire URL+query string (before appending the signature). Assuming 
for now that
the private key is safe on the server, then this would provide a generic way 
to prove
that an incoming request came from a link generated by the site. This 
approach takes
the view that if the user is not meant to see or do something, they are 
never
presented a link in the first place to access it and it is impossible for 
them to fake
a get request that works without knowing the private key. This might 
introduce
peformance concerns.Note that I'm not even talking about public/private key 
crypto
here.. just simple single private key encrypt/decrypt. This would really 
work for any
combination of action+parameters you were concerned about.

I was wondering if anyone out there had any better ideas or advice on how 
they handle
this type of problem in an MVC style application while keeping things fairly 
simple.

Ross

_________________________________________________________________
Hot chart ringtones and polyphonics. Go to  
http://ninemsn.com.au/mobilemania/default.asp


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: Verifying integrity of URLs

["Craig R. McClanahan" <cr...@apache.org>]

Mark McLaren wrote:

> This is an excellent idea!
>
> I hate having to verify the user's request in each action.  Whenever 
> you get a request to add, edit or delete something you have to check 
> that the user actually owns the 'something'.  Usually this is done by 
> modifying the SQL statement when updating the database.  This is 
> painful enough, but sometimes you have to write whole extra statements 
> and check the result just to verify the HTTP request.  Yuk.

Modifying the SQL statement for this purpose sounds like a sub-optimal 
approach.  You'd be better off either defining a security layer that 
would enforce this for you, or use fine-grained role permissions in the 
database to let the DBMS enforce it (although database roles tend to be 
per-table and not per-row).

>
> It would be great if struts could be configured to encrypt the URL so 
> we can trust the request.  This goes for html form elements too. I 
> think the performance hit would be more than compensated for by 
> eliminating unneeded database calls. (Even if it's not, it would still 
> free up a lot of developer time.)
>
> Has anyone looked at doing this?  Is the plugin architecture flexible 
> enough to encrypt the output of the struts-html tags?

It doesn't seem like encrypting the output will help much, unless your 
client can decrypt the data to display it, and then encrypt the 
subsequently submitted input fields.  Otherwise, anyone who is snooping 
the network connection can still impersonate your user.

If you want to avoid snooper-in-the-middle attacks like this, SSL will 
take care of encrypting the network traffic without touching the 
application or the browser.

>
>
> Thanks
>
> Mark 

Craig

>
>
> (p.s. apologies if others have already posted similar comments - 
> Ross's is the only email on this topic I'm aware of)
>
>
> From: Ross Sargant
> Subject: Verifying integrity of URLs
> Date: Mon, 01 Sep 2003 22:00:54 +0000
>
> -------------------------------------------------------------------------------- 
>
>
> Hi,
>    This may be a little off topic, but I thought I'd ask what the 
> experts thought.
> Many actions often take URL parameters. For example a catalog system's 
> "viewItem"
> action might include an id number for the
> item you wish to view. The action uses this ID to pull something out 
> of your RDBMS
> (ideally through a service interface), sets a request attribute and 
> then forwards to a
> JSP to show the relevant data.
>
> Now imagine the case where there are complex rules governing who 
> should be able to
> view what items. Say for example that a certain user can only view one 
> category of
> items (which would obviously be enforced by the search interface-you 
> would never
> generate a link to something they weren't supposed to see in your 
> search results).
>
> What is the best way in general to ensure that the user is not playing 
> around with url
> parameters (in this example by manipulating the id parameter) to get 
> at things they
> shouldn't. Assume for the moment that the RDBMS cannot help you solve 
> the problem.I
> don't really see how Roles help here because my understanding of Roles 
> is that they
> only enable and restrict actions.
>
> One option is to include the security validation in the ViewItem 
> action itself so it
> will not just blindly display whatever object the parameters referred 
> to.This seems
> like a problem that might occur in numerous different places though 
> which means it
> might be benificial to have something more generic.
>
> My other thought was to append a URL parameter that is basically a 
> digital signature
> of the entire URL+query string (before appending the signature). 
> Assuming for now that
> the private key is safe on the server, then this would provide a 
> generic way to prove
> that an incoming request came from a link generated by the site. This 
> approach takes
> the view that if the user is not meant to see or do something, they 
> are never
> presented a link in the first place to access it and it is impossible 
> for them to fake
> a get request that works without knowing the private key. This might 
> introduce
> peformance concerns.Note that I'm not even talking about 
> public/private key crypto
> here.. just simple single private key encrypt/decrypt. This would 
> really work for any
> combination of action+parameters you were concerned about.
>
> I was wondering if anyone out there had any better ideas or advice on 
> how they handle
> this type of problem in an MVC style application while keeping things 
> fairly simple.
>
> Ross
>
> _________________________________________________________________
> Hot chart ringtones and polyphonics. Go to  
> http://ninemsn.com.au/mobilemania/default.asp
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org