5 ms·

Use HSTS. Never use HTTP even to redirect to HTTPS. That is one of the surest ways to prevent users from getting hijacked without knowing it. If you are develo

Use HSTS. Never use HTTP even to redirect to HTTPS. That is one of the surest ways to prevent users from getting hijacked without knowing it. If you are developing any kind of client application where you control the certificate authorities, throw them all away. Use certificate pinning in the client and reject any connections that present a certificate other than your known, pinned, certs. In a web application, keep an eye out for suddenly changing IP addresses. If the user's IP address for a session changes, terminate the session immediately and force the user to authenticate again. This is a common, if paranoid, measure. Alert the user that their IP address has changed. A security warning is sufficient. Most likely they would be getting this attack in a coffee shop or some sort of untrusted Internet connection, so you have to tell them MiTM may be happening and they should be on alert. Defending from the server is hard.

sarciszewski 12y ago
Note that binding sessions to a particular IP is not recommended if your site is designed to be Tor-friendly, as their IP rotates every few minutes.
bradyd 12y ago
> In a web application, keep an eye out for suddenly changing IP addresses. If the user's IP address for a session changes, terminate the session immediately and force the user to authenticate again. If your on a mobile device this may happen often. If you are connected to WiFi and travel out of range you will transition to cellular data, with a new IP. I frequently walk to my sister's house which is ~30 seconds away, looking at a website or app on my phone. During this walk I will transition from my WiFi, to cell, then to her WiFi. It also doesn't protect against your example threat of having your session stolen in a coffee shop, as all users on the same NAT subnet will all have the same public IP, so the server can't distinguish between them.
- bitexploder 12y ago
  It is certainly a trade off. A consumer friendly site/application could never get away with this. In a high sensitivity application you can often get away with it (think large corporation admin type applications, AWS admin when a user is at his desktop, etc.)
harshreality 12y ago
How are you supposed to get them to https the first time if they type in http://site http://site ? I'd suggest rephrasing that to "use HSTS even if you also redirect http to https". Of course it's not secure, technically, but are you willing to annoy (and lose) users until browsers only use https? If you expect visitors only via links, then I suppose you could do away with http, but I don't think any business that cares more about money than about making the world a better place (any public company and most private companies) would want to stop accepting connections on port 80 today. Binding a session to a specific IP might be more secure for the typical case, but it will annoy the living crap out of fringe, but legitimate, users. As already mentioned, Tor users would bear most of the pain and suffering, but if your service supports multipath TCP or something like it, a simplistic "store connecting IP with the session" approach seems like it would cause those users to suffer, too, although not as much. It's also possible the client might be in a corporate environment with corporate SSL (MITM) proxies, and maybe there's a cluster of them so the public client IPs change for different connections. So you'd have to bind sessions to networks, not individual IPs, but what network size do you use? Then even odd MITM attacks that don't use the client's real public IP could use another IP on the same subnet as the real client to connect to the remote service, so how much do you actually gain? If session cookies are httponly and secure, what's the reason for binding sessions to IPs? If it were just Tor, you could set up a hidden service, and detect clients that are connecting from Tor exit IPs and redirect them to the hidden service. But it's not just Tor.
- bitexploder 12y ago
  Binding a session to an IP is just a defense in depth measure. On its own it doesn't buy you a lot, but it is something and it can matter in a small set of circumstances. I would not recommend this as a generalized approach, but I was trying to answer the question. Also, httponly and secure don't help you with a mitm that is ripping apart your SSL. Also, if they type in http:// http://, they simply don't get anything. If you serve even one thing over http:// http://, you give a tool like sslstrip the foothold it needs. Again, this is appropriate for a subset of applications and situations, not a broad, consumer oriented site.
  - 12y ago

sarciszewski 12y ago

Note that binding sessions to a particular IP is not recommended if your site is designed to be Tor-friendly, as their IP rotates every few minutes.

bradyd 12y ago

> In a web application, keep an eye out for suddenly changing IP addresses. If the user's IP address for a session changes, terminate the session immediately and force the user to authenticate again. If your on a mobile device this may happen often. If you are connected to WiFi and travel out of range you will transition to cellular data, with a new IP. I frequently walk to my sister's house which is ~30 seconds away, looking at a website or app on my phone. During this walk I will transition from my WiFi, to cell, then to her WiFi. It also doesn't protect against your example threat of having your session stolen in a coffee shop, as all users on the same NAT subnet will all have the same public IP, so the server can't distinguish between them.

bitexploder 12y ago
It is certainly a trade off. A consumer friendly site/application could never get away with this. In a high sensitivity application you can often get away with it (think large corporation admin type applications, AWS admin when a user is at his desktop, etc.)

harshreality 12y ago

How are you supposed to get them to https the first time if they type in http://site http://site ? I'd suggest rephrasing that to "use HSTS even if you also redirect http to https". Of course it's not secure, technically, but are you willing to annoy (and lose) users until browsers only use https? If you expect visitors only via links, then I suppose you could do away with http, but I don't think any business that cares more about money than about making the world a better place (any public company and most private companies) would want to stop accepting connections on port 80 today. Binding a session to a specific IP might be more secure for the typical case, but it will annoy the living crap out of fringe, but legitimate, users. As already mentioned, Tor users would bear most of the pain and suffering, but if your service supports multipath TCP or something like it, a simplistic "store connecting IP with the session" approach seems like it would cause those users to suffer, too, although not as much. It's also possible the client might be in a corporate environment with corporate SSL (MITM) proxies, and maybe there's a cluster of them so the public client IPs change for different connections. So you'd have to bind sessions to networks, not individual IPs, but what network size do you use? Then even odd MITM attacks that don't use the client's real public IP could use another IP on the same subnet as the real client to connect to the remote service, so how much do you actually gain? If session cookies are httponly and secure, what's the reason for binding sessions to IPs? If it were just Tor, you could set up a hidden service, and detect clients that are connecting from Tor exit IPs and redirect them to the hidden service. But it's not just Tor.

bitexploder 12y ago
Binding a session to an IP is just a defense in depth measure. On its own it doesn't buy you a lot, but it is something and it can matter in a small set of circumstances. I would not recommend this as a generalized approach, but I was trying to answer the question. Also, httponly and secure don't help you with a mitm that is ripping apart your SSL. Also, if they type in http:// http://, they simply don't get anything. If you serve even one thing over http:// http://, you give a tool like sslstrip the foothold it needs. Again, this is appropriate for a subset of applications and situations, not a broad, consumer oriented site.
- 12y ago