1. 31
  1. 12

    Let me play some alternative history here…

    Take something like a shopping cart. If you tried to do this before cookies, when people put a product into a shopping cart on the first page they visited, as soon as they click on anything else, the browser would think this was a completely new visit

    You could create a server-side session on the first POST request adding an item to the shopping cart and add its generated id to all links. A user could even bookmark any of those links to return to their session… If only browsers didn’t rely on cookies for remembering and bookmarking UI wasn’t abandoned.

    Take subscriptions. Without cookies, we have to ask people to manually log in every single time they click on a link. Not just the first time, but between every page view.

    HTTP has an extensible authentication mechanism built-in. If browser’s didn’t rely on sites abusing cookies for user sessions, we could have a universal standard login/logout button working on every site. Instead HTTP authentication UI was abandoned and never progressed beyond incomprehensible modal windows.

    Etc., etc. What I’m saying is, REST (and HTTP/2, as a reference implementation) was designed with all of these in mind (often misunderstood HATEOAS is about that specifically). But, for better or for worth cookies happened and technology went another way. But it was a historical accident, not a technological limitation.

    1. 7

      I think this has many more downsides than first-party cookies. URLs are designed to be shareable; encoding session state into the URL is asking for users to get their accounts taken over through social engineering. “Send me a link” sounds much less malicious than “open your settings page and go to the Advanced section and find your cookies and copy the cookie for this website and send it to me.” It would probably even happen by accident on sites like this one (and Reddit, HN, Twitter, Facebook, etc).

      Not to mention how simple it would make various web attacks, e.g. abusing the Referer header to steal credentials. All you need to do is be able to modify an href attribute and you have an account takeover — that’s not much defense-in-depth.

      IMO first-party cookies, enforced over SSL with the Secure directive, and made inaccessible to JavaScript via the HttpOnly directive, are actually a fairly good mechanism for handling session state. It’s third-party cookies that create tracking issues.

      (Personally I wish cookies were inaccessible to JS by default, and allowing JS cookie access was opt-in, but alas. I also wish sites served over SSL automatically defaulted to Secure cookies. Small but probably meaningful nits.)

      1. 1

        The URL holding state already happens out in the world. One way around your issue would be when you load the state on the server, check if the IP Address/etc changed, plus the time since last seen, etc. If stuff changed , then chances are it’s not the same user, and you can re-prompt for auth, just to verify them again.

        I don’t disagree about 1st party, TLS sent, httpOnly cookies are also an OK way to handle this.

        1. 3

          One way around your issue would be when you load the state on the server, check if the IP Address/etc changed, plus the time since last seen, etc. If stuff changed , then chances are it’s not the same user, and you can re-prompt for auth, just to verify them again.

          This complex and error-prone. It also put the burden on every application developer to understand and know how to make session in URL secure. Too many applications still struggle with basic and solved issues like SQL injection and XSS, I don’t think we would have need yet another common attack vector for web application.

          1. 1

            I don’t disagree with your point, but I’ll just add nobody can get cookies right either, so it’s the same issue(s) for cookies, just in different ways.

            1. 2

              It still seems to me that HttpOnly Secure first-party cookies are better than encoding sessions into URLs. The mitigation factors you describe with URLs are heuristics that can be worked around; for example, if you’re on public WiFi, you and your attacker may share an IP address. Similarly, timing checks are not a strong guarantee.

              People do manage to mess up cookie security as well. But it’s much easier to get cookies right than getting sessions-in-URLs right, and when you get them right you get strong guarantees instead of heuristics. And when you get them wrong, insecure cookies are harder to exploit than insecure URLs: insecure cookies need an attacker who is monitoring traffic or otherwise actively attempting an exploit, whereas anyone could exploit an insecure URL posted to Reddit.

        2. 1

          Fair point, yes. I didn’t think about it.

        3. 4

          Your comment is bringing me memories of ?PHPSESSIONID. One fairly serious drawback is with link sharing. Browsing a shop you’re logged into, you want to share a link to an item with a friend and you inadvertently send them a way into your session.

        4. 3

          Not quite, because the original rfc didn’t require you to have a valid reason for each cookie, just only give cookies from that URL bar’s hostname. In this the original spec was more about usability than GDPR.

          Also not thrilled about the last half of the article. I’m going to pretend it stopped when it mentioned cars.

          1. 2

            Nice article! It also sounds like a fair and logical way to implement such an essential function of a browser. Let it help us build better websites and better user experiences.

            We cannot have anything good though as there’s always someone ready to abuse the system and take advantage of it. So now we have the privacy laws, millions using adblockers and recently even mainstream browsers stopping the malicious behaviour of bad actors by default.