> You can also use a cookieless scheme where the session codes are
> embedded in
> the site URLs so tha they are never stored in the hard disk of the
client
> computer. This alternative has its own pros and cons.
Sadly, one of the "pros" of embedding session IDs is *not* that the
codes are never stored in the hard disk of the client computer. They
will be stored in your browser history, and likely also in your cache.
Also, session IDs in URLs are the easiest way to perform session
fixation attacks. Session cookies are never written to cookie files,
not stored in cache (unless the application is silly enough to embed the
cookie into a response somewhere), and won't show up in your history.
> As outlined in the document mentioned above, SSL with both client
> and server side authentication is not viable, since it would require
> each client to obtain a valid and signed certificate, which is a
> complicated and costly process.
I am familiar with several financial management applications that
utilize client-side certificates. They do this by having the web server
or another backend server generate the certificates and installing them
on the client. The job can also be outsourced to an "online" CA like
Verisign, which will let you generate your client certs and provide you
a webserver plugin that then verifies them.
I must disagree with Kevin's statement that session IDs over SSL are
technically secure but theoretically vulnerable. I may be less than
fully informed about the theoretical vulnerability, of course. Session
IDs are indeed shared secrets, but they are not exchanged "openly" when
SSL is used. By using SSL encapsulation the session ID is protected
from interception or modification. Session fixation, XSS, and other
attacks are still possible, but these vulnerabilities would be difficult
to eliminate in any environment where server-generated script has access
to client credentials and secrets.
Regarding the use of PKI to sign each request to the server, while there
is nothing inherently wrong with this approach, it is not necessary. A
simpler technology when one party wishes to prove knowledge of a shared
secret to another without disclosing the secret is called Zero Knowledge
Proof. This is really just a fancy way of saying "I send you a random
nonce, you hash the nonce and the secret and send the result back to
me".
This zero knowledge proof method is used by Digest authentication to
great effect. When the quality of protection is auth-int, the client
"signs" each request by hashing credential data, the server-supplied
nonce, a server-nonce-counter (if nonces are re-used - note that
including a counter allows a server to detect and reject replay
attacks), the client's nonce to the server, and request information
including method, URI, and message body. The client nonce sent by the
client in the request is used by the server to sign the response, except
that instead of including request information, the hash uses the
response URI and message body.
It is my understanding that the main reason digest is considered
insecure is that, while it provides perfectly adequate protection of
credentials and prevents the session-id stealing attack, it does not
provide message privacy - an attacker may not be able to hijack your
session, but they could still see your account balances and other
information. It is for this requirement, as well as server
authentication via DNS-name to certificate mapping, that the TLS
protocol is put to work.
It may be best to frame this question in terms of requirements and
examine which methods meet which requirements. I believe Kevin's
requirement might be stated: a mechanism must be provided which allows
session state to be preserved, but which does not allow session
hijacking in the face of sniffing.
HTTP Digest Auth: Yes
HTTP + random Session ID: No
HTTPS + random Session ID: Yes
Another interesting requirement would be: a mechanism must be provided
which allows session state to be preserved, but which does not allow
session hijacking in the face of message compromise such as via XSS,
XST, etc.
HTTP Digest Auth: Yes (due to the zero-knowledgeness of it all) HTTP +
random Session ID: No HTTPS + random Session ID: No
For more info on HTTP Digest Authentication, check HTTP: The Definitive
Guide by O'Reilly Press, chapter 13.
Now, the fact that the HTTP spec provides a mechanism that meets our
requirements is fine and dandy, but the real meat of Kevin's e-mail is
this: nobody uses Digest. Everybody uses "random" session IDs. In my
experience, most web applications enjoy the customizability of a
forms-based login. This is why HTTP auth is forsaken - it's got that
nasty bare popup window and it always gives you three tries and then it
just shows you that 401 screen.
The ideal way to solve this problem is to require the browser to treat a
particular kind of login form just like a Digest authentication request.
Perhaps add a "nonce" attribute to the <input type="password"> tag,
and/or a <form content-encoding="auth-digest"> attribute value. When
the form is submitted, the browser could use the username, password, and
nonce fields from the form to generate the necessary Authorization:
header in the request. I guess you would want a new <input
type="username"> to help it figure out which input field was the
username as well. Then web designers could get all the benefits of a
pretty forms login, and app security engineers would get all the
benefits of digest-style authentication, and everybody would be happy!
But we all know how likely that is to get done, unless one of us puts it
into Mozilla or something ;)
Phil
> -----Original Message-----
> From: Ingo Struck [mailto:ingo_at_ingostruck.de]
> Sent: Sunday, July 27, 2003 6:51 PM
> To: Cowles, Robert D.; 'Kevin Spett'
> Cc: 'webappsec_at_securityfocus.com'
> Subject: Re: Problems with most web app auth schemes
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Robert,
>
> > The various web app schemes aren't trying to establish iron-clad
> > security. They are trying to reduce the risk of loss to the client
> > (customer) and server (merchant) to an acceptible level
> without being
> > so intrusive that the clients won't attempt the transaction or be
> > turned away.
> >
> > The reason we can't get better security for current systems is that
> > they pass the "good enough" tests for most clients. Merchants and
> > credit card companies have enough data to understand the
> loss rate. So
> > long as they can recover that in the prices they charge, there's no
> > reason to change (same thing applies to ATMs).
> - From the insurance broker's point of view (which I can
> fortunately follow to
> some extent due to some decent knowledge of statistics) you
> are of course right - the loss of income you lower with
> improved "security" should always outweigh the investment in it...
>
> Alas, such an attitude
> - - is unsatisfactory from a theoretical point of view
> - - does not help to improve things basically
>
> The "good enough" policy is dangerous, because there are
> certainly always some attackers who are willing and able to
> exploit that on a large scale (just like all worst case
> scenarios: they are rather improbable but could be
> devastating if they occur) and it is dangerous because it
> might lower the
> overall trust in your system (some "victims" that you had in
> your calculation
> may be disappointed and not contented with the offered compensation).
>
> On the other hand it is not a real option from a "customers"
> point of view to
> pay the price for only "good enough" systems some supplier
> uses - in a long
> term calculation a "best possible" strategy will surely pay
> off better.
>
> Kind regards
>
> Ingo
>
> - --
> ingo_at_ingostruck.de
> Use PGP: http://ingostruck.de/ingostruck.gpg with fingerprint
> C700 9951 E759 1594 0807 5BBF 8508 AF92 19AA 3D24 -----BEGIN
> PGP SIGNATURE-----
> Version: GnuPG v1.2.0 (GNU/Linux)
>
> iD8DBQE/JFdZhQivkhmqPSQRAmAyAJ988VgEdVnf8so069kd3XfVQiOemQCg0Iu1
> S7E56p/bULbsAIHG9DQskmI=
> =QNaS
> -----END PGP SIGNATURE-----
>
>
>
Received on Jul 29 2003
Intro
