RE: Encrypted URL

[Dean Saxe <Dean.Saxe () digitalinsight com>]

Hey Erik,

We have this problem with our apps.  It appears that MSIE, depending on how
its installed, will sometimes share session cookies between browsers,
causing what you describe below.  Other times it will not share those
session cookies, effectively allowing multiple browser windows to access a
single app and differentiate between them.

Unfortunately, this appears to be an option at installation and I don't know
if it can be changed on the fly through registry settings or preferences.
If it can be changed it would save me a lot of headaches with end users and
QA. ;-)

-dhs

-----Original Message-----
From: Erik Kangas [mailto:kangas () luxsci com]
Sent: Friday, January 30, 2004 11:04 PM
To: mark () curphey com
Cc: Jeff Williams @ Aspect; webappsec () securityfocus com
Subject: Re: Encrypted URL



While using session data is a GOOD idea, there is another case where 
strict use of session data can potentially cause trouble.  That is when 
you have multiple browser windows open in the SAME session.  This is 
easy to do with Internet Explorer - and who is to stop the users from 
doing anything possible....

In this case, what you are doing in one browser window affects the same 
session data store used by the order window.  Since the session is the 
same, the server doesn't differentiate between the windows.  As a 
result, actions performed in one window can affect the results of 
actions in the other window due to the shared session data.

One solution to this is to pass some of the state information in query 
strings or hidden form fields, thus anchoring the volatile part of the 
session to the browser window.  And this is where signing of data or 
other methods already discussed are useful.  As a case in point (though 
I hate referring to Microsoft stuff, it is a good reference point), .NET 
uses hidden form fields to preserve the "ViewState" for its objects for 
just this reason.

-Erik Kangas
Lux Scientiae - http;//luxsci.com




Mark Curphey wrote:
> 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=796f62796c62796e6c62796b621730323a08362b37083a333c30323a0f38796662113e2
97
> > 91c54683b3a312b796e6d620f2d3a1e3c3c302a312b133e2c2b1d3030343631382c1e3c2b7
96
> > 862123e3631113e29e2b363031001e3c3c302a312b123a312a001e3c3c302a312b133e2c2b
1d
> > 3030343631382c791930333b3a2d173e2a4e3033302d62123e3631113e2936383e2b363031
00
> > 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.


-- 

Erik Kangas, Ph.D. --- President of Lux Scientiae, Incorporated

Lux Scientiae:       1-800-441-6612        46 Central Street
FAX:                 1-413-332-0598        Somerville, Massachusetts
Cell:                1-617-596-9558        02143, United States of America
AIM/ICQ/Yahoo Chat:  Screen Name "luxsci"

kangas () luxsci com  ---  http://luxsci.com