Problems with most web app auth schemes

The thread about preventing session hijacking reveals an interesting point that deserves recognition: the login and session id paradigm that most web applications use for authentication is not correct. If you think from the ground up about how authentication should be performed, you do not arrive at what is being used today.

Using a cryptographic strength (in terms of predictability and size) value for a session id over an encrypted connection is pretty secure. You can make this even more difficult to attack by incorporating information such as the client's IP address, various headers, etc into the session id. In the end, you can do a good job making it difficult to pull off session hijacking attacks. In a practical sense, this is effective.

However, even with all of these deterents, it's still not really theoretically secure. Exchanging session id, even one that changes every request or when the server will verify the IP address of the client, has a flaw: you are openly exchanging a secret. This is not how well-designed authentication systems work. It is the equivalent of sending the actual password across a network for a domain login. Even with encryption layer, you're not supposed to do this. You use a hash. The reason for this is so that you can prove that you know the password, but don't actually have to divulge it.

A lot of effort has been spent designing effective authentication systems. It's dissapointing to see that this knowledge is not being applied in fields such as web security that could benefit from it. Guides to web app development rarely if ever make mention of what makes a quality authentication system. More typically, they show you how to store and transmit passwords without hashing, how to use session IDs that were issued without SSL, etc.

Public key cryptography has been around for a long time now. There's not a good excuse for the continued use of the session id system when what web applications really should be using is digital signatures. When the client requests that the server perform an action that requires authentication, it should include a signature: a hash of the request that has been encrypted with a private key. The server should decrypt the hash using the client's public key and then see if the hash is correct. This way, the secret (the private key) says on the client. The server does not need to know it. Even if the transmission is intercepted, the interloper will not be able to generate arbitrary requests that the destination server would recognize as legitimate. SessionIDs do not work this way.

The future of development platforms such as .Net and J2EE will likely have an impact on how authentication is performed in most applications. Fewer and fewer people are rolling their own session classes. Most people will use whatever is provided to them by a major vendor such as Microsoft or Sun. If they decided to provide their users with easy ways of implementing good security procedures, it could work out nicely. If they continue to use sub-standard procedures, or mess up in their implementations, we'll wind up with a whole lot of vulnerable applications.

Kevin Spett
SPI Labs
http://www.spidynamics.com/

Shameless plug: If you're going to be at Blackhat, come check out my presentation on using Java decompilation to find vulnerabilities. I'll be demonstrating how it was used to find a critical vulnerability in BEA Weblogic.
(http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.jsp ) It's currently scheduled for 1:30 PM on the second day of Briefings.

• Original Message ----- From: "Phil Cox" <Phil.Cox@SystemExperts.com> To: <webappsec@securityfocus.com> Sent: Thursday, July 24, 2003 1:33 AM Subject: How to protect against cookie stealing?

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

All,

I have a question on how people are handling cookie stealing and session segregation. For example, it is possible to use session cookie information on multiple systems for most (all?) web applications I know of. Here is a scenario:

When a user logs in he is assigned a BLAH_SESSIONID cookie which serves as an authorization mechanism in the application. The application does not associate the cookie to any session-specific information (e.g., source IP address), so another user can also use the BLAH_SESSIONID cookie to access the same information (over a different TCP/IP session) that the legitimate user can. If an attacker obtains, or guesses a valid BLAH_SESSIONID cookie for an active session, he can use it without the user's knowledge. For example, I was able to execute the following command using an BLAH_SESSIONID that was obtained from another session: Command on Linux box:

  # curl -b "BLAH_SESSIONID=0000FDHTNLVY5WX" https://somesite.com/App/Function?

  Returns the page: (some portion of the returned page)

Historically I have believed that having the application associate the BLAH_SESSIONID session cookie and its associated privileges with a specific SSL session or source IP address would prevent this session stealing. But recently I have been told that this solution does not work because of the dynamic IP nature of MANY ISP's and the disassociation of SSL/HTTP. I would like to know what others are doing to solve this problem, or if they are just not solving it at all.

Thoughts and comments are appreciated...

Phil Received on Sat Jul 26 09:31:40 2003

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek