Problems with most web app auth schemes

["Kevin Spett" <kspett () spidynamics com>]

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?


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