Tristan Seligmann wrote:
* Phil Christensen <[EMAIL PROTECTED]> [2008-08-18 18:44:29 -0400]:
On Aug 18, 2008, at 5:40 PM, Phil Mayers wrote:
potentially possible to forge credentials. I don't know for sure
whether guard checks the IP address of a request against the
original one that created the session in the first place, but even
that could technically be forged.
Caches.
My first guess is that you're referring to caching proxies. I don't
really see how this is an issue, since there's a host of problems you'll
run into if a misbehaving caching proxy is aggressively caching dynamic
content.
Or perhaps the issue you're raising is that there exists a security
issue in that if you are behind a proxy, anyone else behind that proxy
could hijack your session even if the web app session code is checking
the client's IP.
There's also the reverse problem; proxying of requests (or hosts moving
between networks even without proxies) can cause multiple requests in
the same session to come from different IP addresses, thus implementing
this "security measure" will break a significant number of clients, and
is probably a bad idea (since it is also ineffectual).
That's what I was referring to. Apologies for the brevity, I was typing
on a phone handset at the time ;o)
Broadly, caches are perfectly legitimate in HTTP, and it's legitimate
for subsequent HTTP requests to come from different IPs (hell, NAT could
in theory cause that to happen).
So, tying the IP into the authentication is, generally, a bad idea.
Something like Digest HTTP auth is the "safe" way to secure an HTTP
session - you can even (though I've not seen this commonly uses) re-use
the digest session ID as a server-side key into application session storage.
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
