3 ms·

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

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
      Yes, it’s a design choice, in that you have chosen to design something worse for the sake of feeling industrious. There is no need to show a consent banner for authentication cookies (these are considered “Strictly necessary cookies... essential for you to browse the website and use its features, such as accessing secure areas of the site”). On the flip side the directive on tracking consent covers any method of tracking, it doesn’t let you go “nyah nyah, I didn’t use a ‘cookie,’ I made my own and called it something else!” so if you think you would need a banner for a cookie, you will need a banner no matter how you do it.
milesrout 2y ago
I edited it about 10s after posting it.

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
    Yes, it’s a design choice, in that you have chosen to design something worse for the sake of feeling industrious. There is no need to show a consent banner for authentication cookies (these are considered “Strictly necessary cookies... essential for you to browse the website and use its features, such as accessing secure areas of the site”). On the flip side the directive on tracking consent covers any method of tracking, it doesn’t let you go “nyah nyah, I didn’t use a ‘cookie,’ I made my own and called it something else!” so if you think you would need a banner for a cookie, you will need a banner no matter how you do it.

milesrout 2y ago

I edited it about 10s after posting it.