3 ms·

Cookies are entirely a design choice, and a lazy one at that. It is entirely possible to identify, authenticate, maintain session, and store data about a user o

• milesrout 2y ago
  Session information is usually stored in a cookie. It is not better to use a session URI parameter.
  • zelon88 2y ago
    In the proof of concept I linked, a self expiring session token is given to the client. If it is returned before the expiry, a new token is generated and the process starts over. If it is not returned before its expiry the session is considered to have been closed.
    • deleted 2y ago
      [deleted]
    • SirensOfTitan 2y ago
      But how are you storing the session token in the browser?
      • zelon88 2y ago
        In a hidden DOM on the page. Updated asynchronously. There is Javascript running on the page that updates the DOM. So as long as the user is on the page, the "session" stays alive.
        • milesrout 2y ago
          A session by definition extends beyond one page.
          • jdlshore 2y ago
            With some nastiness, you could make every link on the page a form submission and submit the session ID with the form. Then render it into the HTML that’s returned in response.
            • milesrout 2y ago
              A rose by any other name would smell as sweet.
  • zelon88 2y ago
    I see you edited your original comment rather than replying to mine. The URI parameter must be accompanied by the session token and encrypted login credentials as well via POST. So unless you steal the username, hashed password, tokens, and URI parameter before the expiry of the token then you aren't hijacking a user session.
    • zelon88 2y ago
      Basically the web app builds a fingerprinting cookie with a super short lifespan in the page as a hidden DOM. On a set schedule, or with every request, the credentials that are baked into this "DOM cookie" are rotated. When the user stops sending requests the session is closed. Let's say the cookie expiry is 10 seconds, or until the user clicks a button on the page. Any MITM attack is going to have to intercept the HTML over clear text http in order to steal the DOM cookie. That attack would also work on a regular cookie. But with my design the attacker only has 10 seconds to deconstruct that cookie and use it to steal the session. With a regular cookie they have a lot more time. The only other way to hijack the session would be local malware or browser extension, which would also work on a regular cookie.
      • wolfgang42 2y ago
        The only difference between your “DOM cookie” technique and a browser cookie is that it sounds like you’ve (re)invented a session cookie that only works with single-page apps. Either way it boils down to an opaque session ID token which is stored on the client and sent to the server with every request. You could do the same expiry/crosschecking/validation on the server either way; it makes no difference for security how the client stored it. Frankly, this entire codebase is full of code smells that are hallmarks of Dunning-Kruger security (I should know, I was like that myself once!) and the fact that you haven’t learned anything in the 3 years since it was written is alarming.
        • zelon88 2y ago
          So my original comment was accurate then? > Cookies are entirely a design choice, and a lazy one at that. It is entirely possible to identify, authenticate, maintain session, and store data about a user on the server completely without cookies. * By your logic, you're just to lazy to do this better than me and it's just easier to throw banners at everyone?
• wolfgang42 2y ago
  Could you explain how, rather than linking to the middle of a large chunk of code? Fundamentally you need to have some way to associate the data on the server to a particular client, and cookies (or something like them) is the way HTTP does that. In particular, your link appears to be using PHP’s $_SESSION, which... uses a cookie.[1] (Or a URL parameter, but that’s usually a much worse idea than cookies, especially for something that’s handling logins.) [1] https://www.php.net/manual/en/session.idpassing.php https://www.php.net/manual/en/session.idpassing.php
  • zelon88 2y ago
    PHP doesn't have to use a cookie to maintain session. Check my other comment for an explanation.
• Garlef 2y ago
  They are just called "cookie banners". The storage mechanism is not important.