full-disclosure - defense against session hijacking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: damian at sentex.net (Damian Gerow)
Subject: defense against session hijacking

Thus spake David Maynor (dave@...yspray.com) [17/11/03 17:30]:
> This would break things like NATed machines and such.

Could you explain how, please?

If machine A gets NATed to firewall B, and webserver C gets the session...
It's going to record the address of firewall B, not machine A.  I fail to
see how using the connection source's IP address would break NAT.*  And I
don't know what you mean by 'and such'.

Not that I think basing your entire session security on the IP address is a
good idea -- proxies and such.  Using it as *part* of your session security
(onions, people, onions) might work, depending on how a networks
round-robin'ed proxies are set up, if the session really *is* needed to be
carried cross-machine (I've done it before), or any other reason I haven't
thought of yet.

FWIW, (and I know how hated they are), SecurityFocus has a mailing list
specifically for web application security -- webappsec@...urityfocus.com, I
believe.

  - Damian

* = The only thing I could think of is session hijacking, if the source IP
is your only method of session security, by other machines behind the same
NATing gateway.  This is possible.  Again, onions.