[Twisted-web] Session Based Security for PyAmf application

[Phil Mayers]

Tristan Seligmann wrote:
> * Phil Christensen <phil at bubblehouse.org> [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.