But... this doesn't use client to client communication. As far as the AP is concerned there is one client (the attacked). The victim is connected to the attacked believing the attacker is the AP.
To the AP, they are both clients. The attacker (MITM) computer can be accessed by the victim. This would mitigate the attack. It's possible that the arp spoofing would prevent the victim from accessing the internet, but that depends on how the AP institutes it's blocks.
don't take my word for it, but I'd bet you could disallow LAN comms on port 80 and prevent this. Typically a toxic client would flood the arp table until the router believed the toxic client should receive all communications and then the toxic client would mitm and forward traffic on the expected port to other normal clients...if the toxic client can't send stuff on port 80 to a normal client they can't easily mitm them
Yeah, but it would still redirect, since that's a different layer of the IP stack.
You could prevent wifi clients from communicating arp packets, I think that would allow most things to work.
If you have a corporate wifi system, you should be watching for arp poisoning anyway. If it's a public system, most people aren't using it to communicate between wifi devices. Most android devices that communicate via wifi will generate their own wifi network for the duration of the communication.
> is WPA2 on a public Wifi with a publicly known key a workaround?
You're thinking of packet injection (or data intercept) by any nearby individual, which WPA2 with known PSK would mitigate. However, as an attacker would know the PSK, they could simply join the network to side-step this.
I've heard of, although never implemented, using WPA2 Enterprise authentication for public access points, and then just have your RADIUS server reply with a success regardless of username and password combination.
At first I thought this was a terrific idea, but never tried it since I figured having a non-standard workflow for users to connect may cause too much confusion in the end.
And no, that's not a solution. Well at least not everywhere. If the clients aren't completely isolated I can for example poison your DNS and redirect example.com to my computer's web server.
Honestly any decent public wifi setup even if it isn't going to limit client to client communication, if that's needed for some reason, should be restricting based on protocol/port/etc. It should be a whitelist, not a blacklist. There's no reason a client should be able to touch HTTP traffic towards anything but the gateway.
This is trivial to set up with for example, even a cheap sonicwall.