I hear you on that one. My apps always check to ensure a user
has legitimate access to an object before doing anything with that
object. But... that can be a pain, as you pointed out.
So, ways to prevent tampering...
1) Tweak the squeeze adapter to be aware of security constraints.
You could presumably add some sort of Security manager
into which you could pass the "inflated" object.
This is a nice approach in that it centralizes the logic for your
security constraints. Your security manager would need some way to get
access to the current user... (eg: using the threadlocal trick for your
engine so you can get at the visit...) I'm a little unsure, however, on
what should happen should a user /not/ have permission for a particular
object. If you throw an exception, where's it going to propagate to? Is
there any chance to catch it some place reasonable and redirect to a
sort of "permission denied" page or some such? I don't have immediate
answers to that question. You could, of course, change your error page
to be a generic error page (instead of the tapestry one), and not worry
about it... throw your exception, user gets reasonable error page...
everyone is happy?
In general, /any/ approach centered around the squeeze adapter is going
to have that same issue... so you detect url tampering; /then/ what?
Other squeezer-centric methods might be to tweak the adapter to also
write the object hashcode into the url (or some other sort of object
"checksum"). Even if a user tweaks the id, they won't be able to change
the checksum to match. If enough people like this idea, I could write
it into the existing squeeze adapter (again, with the caveat of: now what?).
An option (at least for direct links, see below) for doing this in the
page while limiting redundant code, might be to have every page extend a
"validator" page or some such, that has a method
"validateObjects(Object[] params)"; in your listeners, you can pass in
your object[] array, etc. This would also work for external links; put
the call inside of the activate method (or whatever it's called; I
always forget. :)
This approach isn't going to work so well for, eg, form hidden fields,
but those are "re-inflated" during rewind, before your listener, and you
don't have any single method that you can use for all parameters. That
is, imagine something like the following:
You store an object at the top of the form which contains a
user-specific object being edited. If a user tampered with the "value"
of the hidden field, your form would be rewound, inflating the
(tampered) object, and also /updating/ the tampered object, all before
you had a chance to do anything. There is, however, something of a
solution here, as well, b/c the hidden component allows a listener; you
could write a single listener which ties into your validateObjects
method, and then just use that listener on all your forms.
I feel like I wrote a lot and said very little, sorry. But this is
definitely an area of thought for me, and I'm open to suggestions on
ways to tweak the squeezer to make urls "tamper-proof" /and/ have some
sort of sensible behavior for when urls have been tampered with.
Robert
Gentry, Michael (Contractor) wrote:
>[Maybe I should put this on the Tapestry list, but since it started here
>...]
>
>OK Robert, I'm thinking about DirectLink now, especially since the T4
>docs say that ActionLink is deprecated. :-(
>
>Suppose I did a Cayenne DataSqueezer for Tapestry and then did your
>example of a DirectLink using:
>
> parameter="ognl:someDataObject"
>
>Which generates an URL with something like:
>
> sp=Pnt/DataObject/300
>
>How do you prevent a user from changing that URL to have a 301 or a 302
>or whatever? It is quite trivial to copy the link's URL, paste it in
>the browser address line, and edit it. Record 301 could contain
>personal information for a different person that shouldn't be vended to
>the person receiving the link with 300 in it. It seems like I'm going
>to have to do a lot more defensive programming without ActionLink.
>
>Thoughts on that? I'm curious if you've already solved the malicious
>user problem! :-)
>
>Thanks!
>
>/dev/mrg
>
>
>
This archive was generated by hypermail 2.0.0 : Thu Nov 10 2005 - 12:50:14 EST