3 ms·

Any HTTP request that includes the session cookie needs to be secured, otherwise the firesheep user will be able to grab the session cookie and use it in their

Any HTTP request that includes the session cookie needs to be secured, otherwise the firesheep user will be able to grab the session cookie and use it in their own requests.

mike-cardwell 16y ago
That is the solution to protect websites from the current iteration of FireSheep. It doesn't fix the underlying problem though. If a version of FireSheep comes out that can do MITM we might have bigger problems. The solution to the problem is SSL on every page.
- iuguy 16y ago
  I'm not sure I'm parsing your post correctly, but as I understand it you're talking about third party websites accepting responsibility to protect you over an insecure network connection. If that's the case, then I think you're mistaken. Certainly SSL is not required on every page, and MITM tools have been around for some time (including fairly friendly ones like Cain - http://www.oxid.it/ http://www.oxid.it/). At the end of the day companies such as Facebook, Twitter et al have a moral (and in some cases legal) obligation to protect the information assets you uploaded to their systems from compromise. Likewise it is not unreasonable that you take certain steps to protect yourself. The current version of FireSheep is a real known threat. We don't know what might be in future versions. For protecting against Session ID theft, SSL and the secure flag on cookies are the way to go. Certainly for data that doesn't need to be secure (such as static publicly available graphics), there's no need to use SSL for the majority of use cases. The use of SSL for delivering dynamic client side code (such as HTML or Javascript) is an interesting issue, but ultimately the user has to bear some responsiblity for their own actions somewhere along the line. Not every network is insecure, not every browser has to support a zillion and one insecure means of using Javascript. Rather than using SSL on every page and expecting the web sites to do the heavy lifting, consider not using insecure bearer networks, or some sort of means of securing insecure Internet links such as a VPN or SSH tunnel.
  - mike-cardwell 16y ago
    I do think websites should try to protect their users over an insecure network connection, yes.
    - iuguy 16y ago
      That's an interesting though. Where do you draw the line? Should websites protect users who don't have AV, firewalls or share user accounts?
      - mike-cardwell 16y ago
        I don't think websites should protect users that don't have AV, firewalls or share user accounts no. I also don't think websites should protect users who cross the road without looking both ways. None of those things are relevant to protecting the communications between the website and the user. If the users machine is compromised, that's the users problem. If the users machine isn't compromised, yet the website can't be accessed over an inherently untrustable network like the Internet, then the website has some flaws that it needs to deal with. SSL is a start. DNSSEC is becoming important too and I will be using it on grepular.com when Verisign signs "com" at the beginning of next year.

Any HTTP request that includes the session cookie needs to be secured, otherwise the firesheep user will be able to grab the session cookie and use it in their own requests.

mike-cardwell 16y ago

That is the solution to protect websites from the current iteration of FireSheep. It doesn't fix the underlying problem though. If a version of FireSheep comes out that can do MITM we might have bigger problems. The solution to the problem is SSL on every page.

iuguy 16y ago
I'm not sure I'm parsing your post correctly, but as I understand it you're talking about third party websites accepting responsibility to protect you over an insecure network connection. If that's the case, then I think you're mistaken. Certainly SSL is not required on every page, and MITM tools have been around for some time (including fairly friendly ones like Cain - http://www.oxid.it/ http://www.oxid.it/). At the end of the day companies such as Facebook, Twitter et al have a moral (and in some cases legal) obligation to protect the information assets you uploaded to their systems from compromise. Likewise it is not unreasonable that you take certain steps to protect yourself. The current version of FireSheep is a real known threat. We don't know what might be in future versions. For protecting against Session ID theft, SSL and the secure flag on cookies are the way to go. Certainly for data that doesn't need to be secure (such as static publicly available graphics), there's no need to use SSL for the majority of use cases. The use of SSL for delivering dynamic client side code (such as HTML or Javascript) is an interesting issue, but ultimately the user has to bear some responsiblity for their own actions somewhere along the line. Not every network is insecure, not every browser has to support a zillion and one insecure means of using Javascript. Rather than using SSL on every page and expecting the web sites to do the heavy lifting, consider not using insecure bearer networks, or some sort of means of securing insecure Internet links such as a VPN or SSH tunnel.
- mike-cardwell 16y ago
  I do think websites should try to protect their users over an insecure network connection, yes.
  - iuguy 16y ago
    That's an interesting though. Where do you draw the line? Should websites protect users who don't have AV, firewalls or share user accounts?
    - mike-cardwell 16y ago
      I don't think websites should protect users that don't have AV, firewalls or share user accounts no. I also don't think websites should protect users who cross the road without looking both ways. None of those things are relevant to protecting the communications between the website and the user. If the users machine is compromised, that's the users problem. If the users machine isn't compromised, yet the website can't be accessed over an inherently untrustable network like the Internet, then the website has some flaws that it needs to deal with. SSL is a start. DNSSEC is becoming important too and I will be using it on grepular.com when Verisign signs "com" at the beginning of next year.