All the information that comes from the user-agent can be faked. So the session id is as insecure as any other identifier you get from the Browser. The only thing that could be used is the IP address, and as somebody said earlier, some ISPs and big company LANs may use different proxies for different requests (or use random routes for multiple output interfaces with some NAT gateway). Also the MAC address is not an option, any routing above layer 2? will loose the MAC address (if I'm not wrong).

But there is somehow a way to get it more secure. Basically a key/IP combination would be very secure, it's just not useable for all users. Therefore you need to allow multiple IPs for the same session key. After you see that a user from another IP request a session id, you prompt a login again, and after successfull login you allow both IPs to access this session ID. Every user then basically has to login for each IP he uses; but it could be done more tricky, so the whole subnet that those two IPs are in is allowed. The security risk would be, that any other user going though the same gateway can steal the session just by knowing the correct session id.

If the user is coming through proxies (as it IMHO normally is if you have several IPs for a session), you could even do more fancy stuff. Proxies should send an x-forwarded-for header, where they will add every IP that sent the request (can be multiple hosts). This way you could allow all those proxies for the session, but just for the same end IP (which should be the last IP from the x-forwarded-for field before any internal IP). Now we just have the security hole left, if someone is in control of those proxies, then he could steal the session from the original user.

IMHO this is really everything you can get out of it; you even get it a lot securer for proxied users. The only problem are LANs that use random NAT-Gateways, which IMHO aren't widely spread ??.

If you see anything more to make it secure, or if I'm totally wrong, I'm glad to hear !?

greets, Marcel Greter



--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html



Reply via email to