Would this work as a cheaper alternative to SSL for preventing session hijacking?
1. During the HTTPS part of the communication,
the server sends a long list of random strings.
2. The client stores all these strings in localStorage.
3. On every request, the client sends one of the strings
from the list, the server validates that it is in fact
a valid string for that session, and both remove that
string from their lists.
4. When the list runs out, you have to go back to SSL to
exchange a new list of strings.
Is there a flaw I'm overlooking (beyond the reliance on localStorage) that keeps people from using this?
If not, is there a technical term for this technique so I can Google it?
1. During the HTTPS part of the communication, the server generates a single
random key and sends it to the client.
2. The client stores this string in local storage.
3. For every request, the client generates a HMAC over the request parameters
(including a monotonic sequence number) using the key.
Both of these schemes are still susceptible to a MITM, who can just insert a bit of javascript in any page received over HTTP, that reveals the temporary secret in local storage to anyone listening.
It doesn't. Is it possible to do a MITM attack on the person at the neighboring coffee-shop table?
The only way I can think of involves being really clever about timing and being physically between the other wireless client and the AP: create enough interference to prevent their transmission from getting through to the AP right after you read the transmission, then quickly forge a request using the same one-time key.
Of course, if someone has access to the packets upstream from the AP, you're always hosed if you're not using encryption. This certainly isn't meant as a replacement for AES. :)
DNS (the UDP responses are easy to forge) is a great way to do it. You just have to be faster than the real DNS server, which might be tricky if it's local and caching.
For ARP-based attacks you'd presumably announce yourself as the owner of the default gateway's IP address, routing all data through your system.
Hijacking DHCP springs to mind; respond with an address on a completely different subnet, and your system as default gateway. Again, jackpot.
You could also install a rogue wireless access point with the same SSID, which would let you route all traffic through your system. You just need people's devices to pick yours over the real one, which would presumably require yours to have a stronger signal.
All of the above let you install a transparent proxy which gives you complete control over the target's browser's security context.
Interestingly, the rogue access point would even work with WPA(2)-PSK encrypted wifi, if you knew the key.
But that's the part of the connection we are worried about. End to end encryption from the client to the website is needed. I still don't see where your idea comes in. Clearly I'm not understanding something.
That's kind of like refreshing the session key on every page request except you send over a list of session keys that will be used on subsequent requests. Probably not done since it's usually a hit to the session storage on every page request. Still doesn't encrypt the actual content though, and since SSL would encrypt it and make this unnecessary that's probably why it's not done.
If not, is there a technical term for this technique so I can Google it?