Re: [PEN-TEST] HTTP Secure Session State Management

[Ian Charnas <icc () PO CWRU EDU>]

----[snip]-----
> any others?
> Dom
----[snip]-----

The truly adventurous may notice that persistent connections (denoted by the
"Connection: Keep-Alive" HTTP header) are enabled by default in HTTP 1.1 and
have been available since much earlier generations in the protocol. Keep in
mind that most browsers (all that accept cookies that I know of) always use
persistent connections, other than Mozilla2 and MSIE 4.02b, which have
broken implementations of this feature. Seeing this, the hacker in us wants
to identify a browser instance, or a "session" as some call them, by the
remote IP address and port number.

I submit this is a valid and excellent method of maintaining "sessions" or
"state" or whatever alias you like to use. It doesn't rely on cookies, which
many people have disabled in their browsers. It doesn't rely on a random key
which can be brute forced. It *does* have an obvious but difficult attack:
If attacker A has an account on the same machine as friendly browser B, A
can [on non-trusted operating systems] usually determine which port B is
using to browse, and A can use his own machine to forge some IP packets and
use B's session.

Why does this attack not worry me? Well it relies on the attacker having an
account on our friendly browser's machine. I submit that any modestly adept
attacker A with an account on the same machine as B and vested interest
could and would do much more damage than using B's session. Of course, if
any serious transactions (like those at a bank) needed to take place through
this session, I would use basic authentication over SSL optimally with
client-side certificates to "secure" the transaction. Also, you may want all
your hyperlinks to include the IP address of your server, NOT the FQDN of
your server. This will prevent most man-in-the-middle attacks.

Ian Charnas.