Re: Encrypted URL

[Mark Curphey <mark () curphey com>]

As Jeff points out well, why send the name value pairs to them in the first place to allow them to change them ?

This is one of those logic things that when a developer gets the right frame of mind, he realizes its both more 
efficient and more secure to store the data in an object and use the session token to point to the data stored server 
side. If you have already set it, you have to know it and if you dont want the user to change anything then just don't 
send it down.

The only case I can think of where this would not be true would be when passing data between dns domains or between 
applications that don't share objects or a data source. Even then IMHO I would architecturally advocate a back channel 
rather than passing something over http to the client. Create an API between A and B and then require application A to 
authenticate to B when making the API call giveMeData(curphey); A web service would be a great choice here.   

---- "Jeff Williams @ Aspect" <jeff.williams () aspectsecurity com> wrote:
> You can encrypt querystrings, hidden fields, cookies, or other headers...but
> this only ensures that you get back exactly what you sent to the user.
> Since you already knew all this information (in order to send it), it's
> generally better to use a server-side session to remember that information
> than to route it through the user's browser.
>
> For querystrings, you could use this mechanism to only allow an application
> to be invoked with the parameters that you specify (then encrypt). I think
> it's better to just keep a list of valid ways to invoke the app on the
> server, either in a hardcoded list or a customized session variable. Then
> use a very short URL that is mapped to the list.
>
> Still, there are valid reasons to encrypt if you do not have (or want) an
> ability to store information on the server-side.  This can seriously
> simplify the load-balancing architecture, since you don't have to
> synchronize sessions across multiple servers.
>
> If you decide you need this, remember to build in support for changing the
> encryption key without interrupting all existing sessions. And please don't
> try to invent your own encryption algorithm to do this. Use blowfish or idea
> or something else appropriate to the size and characteristics of what you're
> encrypting.
>
> --Jeff
>
> Jeff Williams
> Aspect Security
> http://www.aspectsecurity.com
>
>
> ----- Original Message ----- 
> From: lupin
> To: webappsec () securityfocus com
> Sent: Friday, January 30, 2004 5:28 AM
> Subject: Encrypted URL
>
>
>
>
> I've seen a couple highly secure Web Application that use encrypted url.
>
> Actually they encrypt the parameter query string.
>
> Example URL:
>
> http://example.com/796e62113e2936383e2b1796d626e676a6f6b6a6b6c67006a/appl?Toto=796f62796c62796e6c62796b621730323a08362b37083a333c30323a0f38796662113e297
> 91c54683b3a312b796e6d620f2d3a1e3c3c302a312b133e2c2b1d3030343631382c1e3c2b796
> 862123e3631113e29e2b363031001e3c3c302a312b123a312a001e3c3c302a312b133e2c2b1d
> 3030343631382c791930333b3a2d173e2a4e3033302d62123e3631113e2936383e2b36303100
> 1e3c3c302a312b123a312a001e3c3c302a312b133e2c2b1d3030343631382c
>
> I think this is a great way to protect against parameter tampering attacks.
>
> Does anybody know more about this technique? Papers etc..? How to implement
> it? Google didn't help me a lot?
>
> What is you point of view? Do you think it will help to prevent all the
> parameter attack (XSS, SQL inj. etc...)?
>
> Thanks a lot for your response in advance.