81–90 of 356 posts
Earlier quoted context omitted.
If you're on the same wireless network as someone, you have the same external IP address.
I realize that but at least my neighbors won't be able to hijack my session from home. Logging in over a public network always seems risky.
What can an end user do to minimize this? This exploit is for insecure Wifi networks- so only using encrypted Wi-fi or Ethernet would seem to remove this attack vector. Is there a real risk that someone (besides the government) can see your cookie?
logging out will cause the captured sessions to be useless. So remember to logout. VPN is really the best overall option.
On reporting it, the response was essentially, "oh you didn't have to go to that much trouble, you could have just used your user/pass from curl…" Completely obvious to the fact that they're app/site was completely vulnerable to session hijacking.
One of the problems of app frameworks, if you don't know what they're doing (and more importantly, not doing) you can get yourself in a heap of trouble before you even realize there's an issue. But boy, you sure can make it to market fast. shakes head
What can an end user do to minimize this? This exploit is for insecure Wifi networks- so only using encrypted Wi-fi or Ethernet would seem to remove this attack vector. Is there a real risk that someone (besides the government) can see your cookie?
vpn/ssh tunnel/encrypted wifi
It will, however, stop unauthorised computers from sniffing any network data.
Once I upgraded to 3.6.10 worked awesome.
Be careful when trying this out. You could be breaking a law or two...
"Double-click on someone, and you're instantly logged in as them." Ouch. I think it's time to set up that VPN I've been putting off...
This way all your communication is encrypted
Instead of sending a cookie, send a piece of javascript code (as part of the SSL-cloaked login handshake) that generates a new cookie for each request, and consider each new cookie in this sequence a "one time use" token. You can turn off SSL for subsequent requests and just use one of these new cookies each time to verify identity because an attacker won't have your cookie generator.
This javascript is really just an encryption key and algorithm, and if you implement it correctly, it should take quite some time for snoopers to reverse engineer the encryption key based on a sequence of one-time-use cookies.
Logistically, I suppose you would run into some trouble setting a new cookie for each request depending on how the page is loaded. For instance, if the user pastes a url into a new tab manually, then this system wouldn't have a chance to set the new cookie first.
However, I think you could architect a system that solves this. For instance, put the javascript token generator source in local storage. If a new page loads with an invalid key, that new page can just get the cookie generator code out of local storage and manually refresh the page's content by making a request with a valid token. This should be quick enough for most users not to notice, in the rare case that they circumvent the site's usual navigation.
A downside is obviously that the content itself is still not safe, but at least the account would be. Any thoughts?