3 ms·

A post I was replying to got deleted, but I'd still like to gripe about the positives and negatives of the current 'web browser + security things' model. Bette

A post I was replying to got deleted, but I'd still like to gripe about the positives and negatives of the current 'web browser + security things' model. Better in the sense of not being locked into an outdated and possibly protocol insecure crypto-system model. Worse in the sense: Random code from the Internet shouldn't have any chance to touch user credentials. At most it should be able to introspect the status of authentication, list of privileges, and what the end user has told their browser to do with that and the webpage. If it weren't for E.G. IE6 and major companies allergic to things not invented there we'd have stronger security foundations but easier end user interfaces to manage them. IRL metaphors such as a key ring and use of a key (or figurative representations like a cash / credit card in a digital wallet) could be part of the user interface and provide context for _when_ to offer such tokens.

hu3 2y ago
> Random code from the Internet shouldn't have any chance to touch user credentials One thing that helps with this are HttpOnly cookies. "A cookie with the HttpOnly attribute can't be accessed by JavaScript, for example using Document.cookie; it can only be accessed when it reaches the server. Cookies that persist user sessions for example should have the HttpOnly attribute set — it would be really insecure to make them available to JavaScript. This precaution helps mitigate cross-site scripting (XSS) attacks." https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
- mjevans 2y ago
  That does nothing to address Credentialing and Authorization issues.
  - hu3 2y ago
    How so? Cookies are the most common way to implement persistent user sessions and by consequence, authn/authz. If it can't be accessed by JS, then it at least does something, to say the least. Could you expand your reasoning?
- blincoln 2y ago
  HttpOnly is mostly a vestigial artifact of the 2000s. As soon as web apps began relying on JS in the browser making calls to APIs, that same JS started needing access to the session token, or credentials equivalent to the session token. If you maintain an app that can get away with an HttpOnly session token cookie, it's a good idea, but unless it's legacy code, it will probably break something, or the JS is getting creds another way and the cookie having the flag set is giving you a false sense of security.
  - ndriscoll 2y ago
    Httponly cookies are still added automatically to js initiated requests. It is not a legacy feature. You don't need to get it another way because you don't need to get it at all in js. It prevents XSS from stealing the cookie and sending it elsewhere (though a successful XSS could still use the cookie while the user is on the page).
    - hu3 2y ago
      Thank you. It's impressive how much misinformation there is in our field. Some people read 1 paragraph from documentation and assume Httponly cookies are useless for SPAs.
ndriscoll 2y ago
It does seem insane to me that we have things like oauth when browsers support (used to support?) client PKI. They just needed a couple pieces of UI to generate a self-signed identity or install e.g. your gmail identity.

hu3 2y ago

> Random code from the Internet shouldn't have any chance to touch user credentials One thing that helps with this are HttpOnly cookies. "A cookie with the HttpOnly attribute can't be accessed by JavaScript, for example using Document.cookie; it can only be accessed when it reaches the server. Cookies that persist user sessions for example should have the HttpOnly attribute set — it would be really insecure to make them available to JavaScript. This precaution helps mitigate cross-site scripting (XSS) attacks." https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

mjevans 2y ago
That does nothing to address Credentialing and Authorization issues.
- hu3 2y ago
  How so? Cookies are the most common way to implement persistent user sessions and by consequence, authn/authz. If it can't be accessed by JS, then it at least does something, to say the least. Could you expand your reasoning?
blincoln 2y ago
HttpOnly is mostly a vestigial artifact of the 2000s. As soon as web apps began relying on JS in the browser making calls to APIs, that same JS started needing access to the session token, or credentials equivalent to the session token. If you maintain an app that can get away with an HttpOnly session token cookie, it's a good idea, but unless it's legacy code, it will probably break something, or the JS is getting creds another way and the cookie having the flag set is giving you a false sense of security.
- ndriscoll 2y ago
  Httponly cookies are still added automatically to js initiated requests. It is not a legacy feature. You don't need to get it another way because you don't need to get it at all in js. It prevents XSS from stealing the cookie and sending it elsewhere (though a successful XSS could still use the cookie while the user is on the page).
  - hu3 2y ago
    Thank you. It's impressive how much misinformation there is in our field. Some people read 1 paragraph from documentation and assume Httponly cookies are useless for SPAs.

ndriscoll 2y ago

It does seem insane to me that we have things like oauth when browsers support (used to support?) client PKI. They just needed a couple pieces of UI to generate a self-signed identity or install e.g. your gmail identity.