Re: Question re session hijacking in dual stack environments w/MacOS
I can¹t speak to every case, but I ran into a similar issue with our WAF product, so I can explain what was happening there. Most Web application firewalls have cross-site request forgery protection. When a form is downloaded, the firewall inserts a hidden field or cookie that contains the IP address of the request. When the form is submitted, the firewall then verifies that the post is sent from the same address. If the client does a get via IPv6, and the form contains a form action for a URL that is better reached via IPv4 then the firewall sees the post coming from a different IP address and refuses the request. This is nothing specifically to do with MacOS, it is true of any multi-homed system. The options are either to rewrite the client to guarantee that the address in a post always matches the corresponding get; to maintain different URLs on the server such that requests from IPv6 clients always return action URLs that will go to an IPv6 hostname, and vice-versa for IPv4; or to disable CSRF protection. Later, John
From: David Hubbard <dhubbard@dino.hostasaurus.com>
Hey all, as we've slowly deployed IPv6 to our end users, it has begun to cause some issues for those on Mac's specifically. Apple apparently has an algorithm at some point in the network stack to decide whether IPv4 or IPv6 is, perhaps, 'better' or 'faster' at any given point in time during an ongoing session. This allows a computer talking to a dual stack remote website to flip flop between v4 and v6 as activity is conducted.
Websites that require some type of authentication that is handled via session cookies have been booting our users out randomly with "your ip address has changed" type message. This occurs when their Mac decides to switch between protocols because the site views it as a session hijacking attempt when Joe User with session ID xyz switches from 192.0.2.10 to 2001:db8::1:1:a or vice versa.
Has anyone run into this? Our users on other platforms don't seem to have this issue; linux and MS desktops seem to just use v6 if it's available and v4 if not.
Thanks,
David
On 2015-09-27 12:24, John Schimmel wrote:
Most Web application firewalls have cross-site request forgery protection. When a form is downloaded, the firewall inserts a hidden field or cookie that contains the IP address of the request. When the form is submitted, the firewall then verifies that the post is sent from the same address.
This reminds me of ICMP blocking which breaks path MTU discovery and thus blocks all users with < 1500 MTU. The technique described here doesn't sound like it would protect from XSS or CSRF; it would just introduce seemingly random failures like the OP described. The idea with trying to tie the apparent network address to a session is to make session hijacking harder, not local scripting attacks (which could come from the same address anyway), but it's a bad idea regardless because there is not normally a reason for a session to be 'sticky' in this way and so there's no effort made to keep the same address, it just happens by accident sometimes. Making this work so the WAF can be happy is in conflict with actually useful things like load balancing, cache proxies, privacy addresses, etc. It probably works some percentage of the time for some users, and those who it doesn't work for just get blamed for having a bad browser/computer/ISP/whatever. I hope that as the failure rate increases, people using these solutions eventually realize that they're blocking themselves off from the net. -Laszlo
participants (2)
-
John Schimmel -
Laszlo Hanyecz