Aloha, Tony.

Your thinking comes up in this discussion each time I have it with
others, and it gets everyone all flustered because it makes sense
on the surface: trust the browser to be reliable and you can build
a nonce into HTTP at the application level similar to RFC 2831
Digest Authentication as a SASL Mechanism.

http://www.ietf.org/rfc/rfc2831.txt

To paraphrase your suggestion, the server uses Set-Cookie to
provide a nonce to the client and requires that each request sent
by the client subsequent to the Set-Cookie supply the nonce else
the client request is rejected as a malicious replay. Set-Cookie
is issued only with responses that deliver HTML to the browser,
and frames are never used so that only a single HTML document is
delivered to the client in response to a given "page" request.

The reason this thinking fails is three-fold:

1) A man in the middle simply hijacks the session by sending the
valid nonce, at which point the MITM is the only one who receives
the next nonce from the server's next Set-Cookie, denying access
to the authentic user.

2) Proxy server cache may deliver Set-Cookie values to multiple
clients if the Set-Cookie header is issued in response to a GET
request -- Set-Cookie headers issued by a server in response to
a POST request are not vulnerable to this proxy cache flaw due
to the fact that the POST by definition depends on both the body
and the headers in the request, an aggressive proxy server cache
will only have a possibility of issuing a duplicative Set-Cookie
in response to a POST request if the POST body and headers match
exactly with the body and headers sent by another client (or the
same client) previously through the same proxy server. See MS KB
article # Q263730

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q263730

3) The browser is not reliable. Not only do cookies get handled
(and mishandled) differently by various browser make, model, and
version, the server has no way to know for sure that the browser
received the subsequent Set-Cookie. Consider that a proxy server
will receive the HTTP response from the server through an open
TCP connection and the server will close the connection after it
is satisfied by TCP that the transmitted packets arrived at the
intended destination reliably. This does not mean that the real
end user client browser has received the HTTP response, it only
means that the server has completed its best-effort requirement.
The proxy server still has to relay the response to the browser.

What you CAN reliably do with a browser is send it a cookie in
response to a POST request which supplied valid credentials and
require that it send the cookie back to you or else you refuse
to continue the conversation. If you use a cryptographically
secure session identifier and expire session identifiers when
the sessions end you get the data security features you need
and want without unreasonable and pointless complications.
Disallow "remember me" long-lived sessions and automatically
detect and block brute force attacks that attempt to randomly
guess valid session identifiers -- these are the best practices
of Web application security for servers that are unwilling or
unable to use SSL.

A classic replay attack follows this thought process:

"I don't understand what the client just said, but it made the
server do something. If I record what the client just said,
perhaps I can replay it later and the server will do the same
something for me."

Therefore my #1 above isn't a classic replay attack, it's just
one of the things a man in the middle attacker can do with full
plaintext of the conversation and the ability to understand the
nature of the plaintext. Call it a "credential capture" attack
if you like, even though the "credentials" in this scenario are
only good for authenticating as the client for whatever purpose
the server permits within the context of the hijacked session
and doesn't give the attacker full credentials for later use.

But I don't mean to disparage your comments because of minor
terminology abuse -- my real point is that replay attacks are
irrelevant if the attacker has full access to plaintext. Why
would the attacker throw any replay data at the server to see
what it can make the server do when it knows how to extract
parts of the plaintext to construct a brand new valid request?

Anyone care to explain why SSL isn't vulnerable to replay
attacks? The client generates the secret used in the symmetric
encryption, and the server doesn't have any mechanism that I'm
aware of to expire/reject symmetric keys generated by the
client, so the server would have to supply the client with an
initialization vector during SSL handshaking, otherwise there
would be no way for the server to know that the encrypted data
sent by the client, which the server can successfully decrypt
using the symmetric key provided to it by the client, is replay
data and not authentic original data. Or perhaps key exchange
includes a time stamp or other server-supplied value that the
client must send back along with the chosen secret key in its
part of the key exchange discussion. I haven't analyzed the
SSL protocol and its key exchange implementation looking for
answers to these questions yet.

Aloha & Mahalo,

Jason Coombs
jasoncscience.org

-----Original Message-----
From: Tony Welsh [mailto:listsevolvedcode.net]
Sent: Saturday, April 27, 2002 12:27 AM
To: David Voss
Cc: webappsecsecurityfocus.com
Subject: RE: Alternatives to session IDs as authenticators?

Wouldn't spawning multiple instances from the same browser mean that the
browser was at least *technically* capable of sharing cookies between the
instances? (given that the two windows are a single application)

This is at least true of IE;

If I'm on a very session sensitive site and spawn a second window
(instance), this second instance keeps on using the same session as before -
it will present the session cookie from the first instance when it makes a
request and so will not be issued a new session.

If I were to then add a new session cookie into the second instance, then
test for the existence of that cookie in the first instance it will show
there are now two session cookies for instance one despite the fact that it
personally only ever received one of those cookies.

Given that the essence of a transaction based system seems to be (from what
I can understand) that each request generates a new session cookie, then
would this not mean that linear browsing is not a problem and the only thing
you need to worry about is the browser not retrieving the latest session
cookie? e.g. when loading a sequence of objects you cannot guarantee the
delivery order of those objects, or if I issue a request for a page, use up
my transaction and fail to get data back due to some comms error or other.

Wouldn't a partial solution to this be to supply these updated cookies only
for the object you are trying to secure and not things like images, pop-ups
etc. which would most likely not need to be secured?

Regards - Tony

-----Original Message-----
From: David Voss [mailto:DVosskalmbach.com]
Sent: 25 April 2002 22:18
To: webappsecsecurityfocus.com
Subject: RE: Alternatives to session IDs as authenticators?

In regards to the transaction method, this would work great as long as
people use the site in a linear manner. If you have people who like to
spawn multiple windows for a site, then it would create problems.

For example, someone is in the process of checking out of the cart. They're
filling out personal details, but they remember they'd like to buy one more
thing. They open a new window, check out a few more items and finally add
one more to the cart. The person then returns to the other window,
completes the form and submits. Now they're faced with an error or invalid
session message because their transaction id has been incremented by the
other window adding more items to the cart.

Or...what if someone simply clicks on a help icon, which opens a popup
window and causes the transaction id to be incremented? When the current
page is submitted, it's transaction id will be invalid.

Just something to consider.

-Dave

>Still there is another thing to prohibit replay attacks even on
>HTTP connections:
> Transaction management.
>
>The idea is as follows:
>For each response the server generates a transaction id that is
>internally stored as a session attribute. The transaction ids
>have to be ordered, i.e. the _real_ transaction id for each response
>must be larger than the former transaction id.
>The server encrypts the _following_ transaction and sends it with
>the response to the client.
>Any input data sent from the client will be accepted only if
>the decrypted incoming transaction id is larger than the actual
>transaction id internaly stored in the session.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]