From: "Craig R. McClanahan" <[EMAIL PROTECTED]> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: Struts Users Mailing List <[EMAIL PROTECTED]> Subject: Re: Verifying integrity of URLs Date: Sun, 05 Oct 2003 09:58:56 -0700
Mark McLaren wrote:
So how do you convince your client browser to play along? Wouldn't it have to know how to decrypt the data (to display it to the user) and then encrypt it again? If you used, say, JavaScript for this purpose, aren't you exposing the encryption algorithm (and therefore still making it possible to mess around with the request parameters?
From: "Craig R. McClanahan" <[EMAIL PROTECTED]> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: Struts Users Mailing List <[EMAIL PROTECTED]> Subject: Re: Verifying integrity of URLs Date: Sat, 04 Oct 2003 14:04:19 -0700
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).
Yes there are probably better ways to check the user has permission to submit that particular request, but surely the easiest would be to add 'encrypt=true' to a config file and let struts (or a struts plugin) do the check.
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.
It wouldn't protect against snooper-in-the-middle attacks but would protect against mess-around-with-the-request-parameters attacks. SSL solves the first problem while URL-encryption would solve the second.
Craig
I was thinking the text that gets displayed to the user would not be encrypted, only the 'unseen' stuff. So for example, a link like this:
<a href="/deleteEmployee.do?employeeId=473">Delete John Doe</a>
would be encrypted as: <a href="/deleteEmployee.do?employeeId=xP458Aqjf68nbiif">Delete John Doe</a>
Similarly, a form like this: <form action="/updateEmployee.do" method="post"> <input type="hidden" name="id" value="473"> <input type="text" name="name" value="John Doe"> <select name="department"> <option value="12" selected>Sales <option value="17">Management <option value="20">Engineering </select> <input type="submit"> </form>
would be encrypted as: <form action="/updateEmployee.do" method="post"> <input type="hidden" name="id" value="J74poq11zicwfwo"> <input type="text" name="name" value="John Doe"> <select name="department"> <option value="o0fjPVzA12fLLS" selected>Sales <option value="Xwqof84nfiwo">Management <option value="fODjf7vk39fyh">Engineering </select> <input type="submit"> </form>
(The encrypted values should be different for each response, so maybe it's necessary to also have a 'request token' hidden parameter whose unencrypted value is the key to the department ids)
- Mark
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________ On the move? Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
