3 ms·

>>> As haxta4ok00 suggested, one step was to bind authentication cookies to the IP address of the user it was issued to. Do NOT bind session cookies to an IP.

>>> As haxta4ok00 suggested, one step was to bind authentication cookies to the IP address of the user it was issued to. Do NOT bind session cookies to an IP. It breaks usability on mobiles, they change networks quite often. What you can try to do instead is to associate the cookie to the country is user currently is in. It's available in the CF-IPCountry header if you use CloudFlare. This may also cause usability issues for frequent travelers or border workers. https://support.cloudflare.com/hc/en-us/articles/200168236-Configuring-Cloudflare-IP-Geolocation https://support.cloudflare.com/hc/en-us/articles/200168236-C...

jsploit 7y ago
Locking sessions to countries doesn't offer any security benefit - an attacker can quite trivially connect from an IP in any target country.
- user5994461 7y ago
  Lock out the login page too so users can't login from countries you don't do business with, especially the actively hostiles ones (CN, RU, T1). It's simple and it's extremely effective. It benefits security immensely.
  - jsploit 7y ago
    I don't understand how it's anything beyond a minimal defense-in-depth measure. 1. Target leaks session cookie 2. Attacker uses VPN to connect from target's country with the leaked session cookie 3. Attacker's session is deemed valid
    - user5994461 7y ago
      Attackers usually don't know the country of the user. Even if they do, it's not as easy as it sounds to find a VPN or an open proxy in any country. If you're thinking of Tor, Tor is trivial to detect and block. I've been working in fintech companies and e-commerce, handling real money or wallets that could be stolen or emptied by a successful attacker. If you don't do defense in depth, users lose. One trivial example, the days after a new breach is published on Hacker News, there will be bots on the door attempting to brute force login with all these new email and password combinations. Any other question? I feel like I have a context to start writing a blog post on that.
      - jsploit 7y ago
        > Attackers usually don't know the country of the user Nothing a little recon or social engineering can't solve. > it's not as easy as it sounds to find a VPN or an open proxy in any country Only for some small/niche countries perhaps. Worst case, an attacker can rent a VPS in the target country. Perhaps a city-based lock would be more effective.
        user5994461 7y ago
        Most attacks are opportunistic, trying credentials that were leaked online or brute forcing simple passwords. It's also heavily weighted from russia, china, tor, open proxy, non-reputable hosting and cheap VPS. Each of these can be detected and blocked. Attacker do not maintain proxies, especially not proxies across tens of developers countries, and if they that would be organized crime and it's a whole new level. By the way, banking trojans evolved to operate from the browser of the victim specifically to evade these protections. Should I cover all these in a blog post if it's something you're interested in?
        jsploit 7y ago
        I think you're deviating from the topic of protecting against the vulnerability HackerOne encountered: using a leaked session cookie. In their case, let's say the victim analyst was based in the United States, and they have implemented your proposed session country-lock. I also happen to reside in the US, so the country-lock protection is worthless. For other cases, you can _try_ to block proxies, VPNs, TOR, VPSs... but that in itself is perhaps a usability fail.
dcow 7y ago
What you should actually do is use short lived authorization tokens (maybe 30s, clamped by the user agent) derived from a longer lived session secret. You can even bind the short lived request tokens individually to an IP since the client is doing it for each request. Macaroons make this rather simple. That way there’s no risk in sharing request logs.
andreareina 7y ago
The report[1] calls out binding the cookie to the IP as only being a temporary measure, exactly because it's a usability problem. Their longer term solution is to bind the cookie to the device (how?) [1] https://hackerone.com/reports/745324 https://hackerone.com/reports/745324

jsploit 7y ago

Locking sessions to countries doesn't offer any security benefit - an attacker can quite trivially connect from an IP in any target country.

user5994461 7y ago
Lock out the login page too so users can't login from countries you don't do business with, especially the actively hostiles ones (CN, RU, T1). It's simple and it's extremely effective. It benefits security immensely.
- jsploit 7y ago
  I don't understand how it's anything beyond a minimal defense-in-depth measure. 1. Target leaks session cookie 2. Attacker uses VPN to connect from target's country with the leaked session cookie 3. Attacker's session is deemed valid
  - user5994461 7y ago
    Attackers usually don't know the country of the user. Even if they do, it's not as easy as it sounds to find a VPN or an open proxy in any country. If you're thinking of Tor, Tor is trivial to detect and block. I've been working in fintech companies and e-commerce, handling real money or wallets that could be stolen or emptied by a successful attacker. If you don't do defense in depth, users lose. One trivial example, the days after a new breach is published on Hacker News, there will be bots on the door attempting to brute force login with all these new email and password combinations. Any other question? I feel like I have a context to start writing a blog post on that.
    - jsploit 7y ago
      > Attackers usually don't know the country of the user Nothing a little recon or social engineering can't solve. > it's not as easy as it sounds to find a VPN or an open proxy in any country Only for some small/niche countries perhaps. Worst case, an attacker can rent a VPS in the target country. Perhaps a city-based lock would be more effective.
      - user5994461 7y ago
        Most attacks are opportunistic, trying credentials that were leaked online or brute forcing simple passwords. It's also heavily weighted from russia, china, tor, open proxy, non-reputable hosting and cheap VPS. Each of these can be detected and blocked. Attacker do not maintain proxies, especially not proxies across tens of developers countries, and if they that would be organized crime and it's a whole new level. By the way, banking trojans evolved to operate from the browser of the victim specifically to evade these protections. Should I cover all these in a blog post if it's something you're interested in?
        jsploit 7y ago
        I think you're deviating from the topic of protecting against the vulnerability HackerOne encountered: using a leaked session cookie. In their case, let's say the victim analyst was based in the United States, and they have implemented your proposed session country-lock. I also happen to reside in the US, so the country-lock protection is worthless. For other cases, you can _try_ to block proxies, VPNs, TOR, VPSs... but that in itself is perhaps a usability fail.

dcow 7y ago

What you should actually do is use short lived authorization tokens (maybe 30s, clamped by the user agent) derived from a longer lived session secret. You can even bind the short lived request tokens individually to an IP since the client is doing it for each request. Macaroons make this rather simple. That way there’s no risk in sharing request logs.

andreareina 7y ago

The report[1] calls out binding the cookie to the IP as only being a temporary measure, exactly because it's a usability problem. Their longer term solution is to bind the cookie to the device (how?) [1] https://hackerone.com/reports/745324 https://hackerone.com/reports/745324