WebApp Sec mailing list archives
RE: Problems with most web app auth schemes
From: "Brass, Phil (ISS Atlanta)" <PBrass () iss net>
Date: Tue, 29 Jul 2003 00:31:48 -0400
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 () ingostruck de] Sent: Sunday, July 27, 2003 6:51 PM To: Cowles, Robert D.; 'Kevin Spett' Cc: 'webappsec () 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 levelwithout beingso 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 theloss rate. Solong 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 () 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-----
Current thread:
- Re: Problems with most web app auth schemes, (continued)
- Re: Problems with most web app auth schemes Brant Langer Gurganus (Jul 27)
- Re: Problems with most web app auth schemes Tim (Jul 27)
- Re: Problems with most web app auth schemes George W. Capehart (Jul 27)
- Re: Problems with most web app auth schemes Tim (Jul 27)
- Re: Problems with most web app auth schemes George W. Capehart (Jul 28)
- Re: Problems with most web app auth schemes Tim (Jul 27)
- Re: Problems with most web app auth schemes Brant Langer Gurganus (Jul 27)
- Re: Problems with most web app auth schemes Ingo Struck (Jul 27)
- Re: Problems with most web app auth schemes Ingo Struck (Jul 27)