Re: [PEN-TEST] Your opinions are solicited ...

[Paul Robinson <paul () AKITANET CO UK>]

On Tue, 31 Oct 2000, Frank Knobbe wrote:

> IP authentication? In today's world or access through NATed firewall
> or proxy servers, or providers like AOL, all in an Internet
> environment increasingly becoming akamaied... uhm... cached, I
> strongly doubt that IP authentication is viable. Take AOL users for
> example: One request appears to be coming from proxy1.aol.com, the
> next request from proxy3.aol.com. That would mean that your 'IP
> authenticated' web page will invalidate the second request.

I didn't explain fully, and this is something probably best to goto secprog
than here, but I'll try and give a quick overview of how I would do this.

You are right that proxies can cause a problem here, but even in those cases,
most proxies (that behave, anyway) normally pass an extra HTTP environment
variable called HTTP_X_FORWARD which will actually reveal the real IP address
being used on the public interface - regardless of NAT. In addition, the
REMOTE_ADDR variable will hold the IP address of the cache engine/proxy being
used. If you use the two combined, you're going to secure things down a
little more, and it's now going to be very difficult for an attacker to steal
the session (especially as your cookies that are being passed around and
changed on every transaction/page reload are travelling over SSL), apart from
when you're in a NAT'ed environment.

In this situation, HTTP_X_FORWARD is going to hold the IP address of the
public side of the router, most probably dynamically allocated by your ISP,
or perhaps if you have a gateway box doing NAT on the end of a leased line.
In this scenario, it is conceivable that somebody can sniff your cookie, and
from their own machine, they are going to appear to be you. That's the only
hole, so you get around that by updating cookies as well in the following
manner:

- User goes to homepage, given cookie with say 20 minute expiry, which is
logged locally into say an SQL database with the HTTP_X_FORWARD (if present)
and REMOTE_ADDR values.

This bit is repeated as the user goes through the site:

- User goes to next page. Cookie retrieved, and checked against SQL table,
along with (you guessed it) HTTP_X_FORWARD and REMOTE_ADDR.
- If everything matches up, you now set a new value for that cookie with the
client, and update the value of the cookie you store locally
- If it doesn't match, you assume there is a problem, and don't serve secure
content. Instead, you ask the user to re-authenticate themselves, reset the
cookie, and off you go.

In addition, you mark your cookies as secure so they are not going to be sat
in plaintext on the client's machine, and by definition are then going to
have to be transmitted over SSL. If you're in a NAT environment, you are
going to need to have somebody sat there able to not only break the SSL
session keys, but even once they have your cookie, it will only work until
you go to another page - at that point, the problem is detected (there is a
cookie mismatch, as the cookie you have doesn't match the one the attacker
has), and so the real user has to authenticate himself again.

To some extent, there is still a hole here however in that the user still
needs to have strong authentication, but this method is about as strong a
method I can think of to prevent session hijacking at the application level.

I'd be interested to hear any holes or better methods you guys can come up
with.

--
.------------------------------------------------------------------------.
| Paul Robinson - Technical Director @ Akitanet - http://www.akita.co.uk |
|------------------------------------------------------------------------|
| T:+44 (0) 161 228 6388  F:+44 (0) 161 228 6389  E: paul () akitanet co uk |
`------------------------------------------------------------------------'