WebApp Sec mailing list archives
Re: Encrypted URL
From: Erik Kangas <kangas () luxsci com>
Date: Fri, 30 Jan 2004 23:03:31 -0500
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: lupinTo: 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.
-- 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
Current thread:
- Re: Encrypted URL, (continued)
- Re: Encrypted URL Kenneth Peiruza (Jan 30)
- Re: Encrypted URL Ulf Härnhammar (Jan 30)
- Re: Encrypted URL Daniel Souza (Jan 30)
- Re: Encrypted URL David Wall @ Yozons, Inc. (Jan 31)
- RE: Encrypted URL Hephaestus (Jan 30)
- Re: Encrypted URL Daniel Souza (Jan 30)
- Re: Encrypted URL Fogbound Child (Jan 30)
- RE: Encrypted URL scott wood (Jan 30)
- Re: Encrypted URL Mark Curphey (Jan 30)
- Re: Encrypted URL gcb33 (Jan 31)
- RE: Encrypted URL Scovetta, Michael V (Jan 31)
- Re: Encrypted URL Erik Kangas (Jan 31)
- RE: Encrypted URL Dean Saxe (Feb 02)
- Re: Encrypted URL Jeremiah Cornelius (Feb 02)
- Re: Encrypted URL Fred van Engen (Feb 02)
- Re: Encrypted URL Jeremiah Cornelius (Feb 02)
- RE: Encrypted URL Dean Saxe (Feb 02)
- Re: Encrypted URL Brecrost Jones (Feb 02)