Bare Parameters in the URL

[Lance Arlaus <la...@codeberet.com>]

In running the DirectLink sample, it looked like a malicious user could
easily replace parameters by manipulating the URL.

Sure enough, fiddling with a running sample confirmed it.

Other than manually checking incoming parameters, has anyone devised a
simpler, less error prone strategy to automatically reject malformed URLs?

I would think the parameters would be abstracted and not supplied directly
in the URL!

 

Re: Bare Parameters in the URL

[ro...@scazdl.org]

> In running the DirectLink sample, it looked like a malicious user could
> easily replace parameters by manipulating the URL.
>
> Sure enough, fiddling with a running sample confirmed it.
>
> Other than manually checking incoming parameters, has anyone devised a
> simpler, less error prone strategy to automatically reject malformed URLs?
>
> I would think the parameters would be abstracted and not supplied directly
> in the URL!
>

There are a number of ways of abstracting things.
But, really, it depends on whether you think editable urls are
a good thing or a bad thing. :)
That said, a simple way of abstracting things is to specify, eg, the index
into a list of objects rather than, eg, a primary key as the parameter,
and then grab the appropriate object based on the list index.
You can also write your own DataSqueezeAdapter for your objects
and abstract things in whatever way seems suitable to you (eg:
you could extract the pk of the object, then encrypt it, and store the
encrypted form as the parameter.).

Robert

>
>
>


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