6 ms·

I disagree with his argument that JSON web tokens are "less secure". He even quotes this: > The only way to retrieve data out of local storage is by using Java

I disagree with his argument that JSON web tokens are "less secure". He even quotes this: > The only way to retrieve data out of local storage is by using JavaScript, which means any attacker supplied JavaScript that passes the Content Security Policy can access and exfiltrate it. In my opinion, it is MUCH easier to get a CSRF vulnerability than it is to bypass the Content Security Policy. Unless you can get around the CSP and same origin requirement, this makes web tokens far more secure. He also states that if you store your web token in a cookie you are still vulnerable to CSRF. This is only true if you are using cookie headers to send the token (which is less common), not if you only use it for storage/retrieval of the token. Lastly, he argues JSON web tokens are not easier to use, but then points out you need a dedicated Redis session store server to scale session authentications. Managing sessions in mobile apps and command line apps is a huge pain compared to JWTs. How is that easier to use?

joepie91_ 10y ago
CSRF vulnerabilities are less severe than a stolen session. I've addressed the reason for that here: https://www.reddit.com/r/PHP/comments/4nwpvg/stop_using_jwt_for_sessions/d47larg https://www.reddit.com/r/PHP/comments/4nwpvg/stop_using_jwt_... > This is only true if you are using cookie headers to send the token (which is less common), not if you only use it for storage/retrieval of the token. That's the normal mode of operation for cookies, and what you should assume the client to do. > Lastly, he argues JSON web tokens are not easier to use, but then points out you need a dedicated Redis session store server to scale session authentications. At a scale where you can't just store the sessions in the database you're already using (or on disk - see PHP), the added complexity of a single Redis server is negligible. Below that scale, you can just use your regular database, at no additional complexity cost. > Managing sessions in mobile apps and command line apps is a huge pain compared to JWTs. I've heard a few people claim this now, but none have been able to explain exactly how it's a "huge pain" or "more complex". Care to elaborate?
SCHiM 10y ago
I've tested many web applications, and around 80% of all applications I've tested contained an XSS of some sort or another, that number drops to around 40% if you only look at stored XSS & XSS in a get request. And to less than 10% when only looking at stored XSS. Unless you've used cookies with the HttpOnly flag XSS trivially escalates to session stealing. Do NOT store sessions in anything other than cookies with the HttpOnly (and really, SecureFlag) flag set. Using javascript to manage your sessions only the client side in any way is NOT secure.
- mwpmaybe 10y ago
  > Using javascript to manage your sessions only the client side in any way is NOT secure. And yet it's common practice, at least in the SPA communities with which I engage on a regular basis.
- jupenur 10y ago
  > Unless you've used cookies with the HttpOnly flag XSS trivially escalates to session stealing Then again you could just use CSP and mitigate almost 100% of those XSS cases. Yes, even most of the stored ones. And with JWT + JavaScript you don't have to worry about all the oddities in the way cookies work, which is a huge plus.
  - mwpmaybe 10y ago
    CSP isn't a silver bullet.
    - seangrogg 10y ago
      Nor is HttpOnly, really.
      - mwpmaybe 10y ago
        I never said it was.
- merb 10y ago
  if you are vulnerable to XSS your HttpOnly cookie won't help you.
  - SCHiM 10y ago
    You are wrong. It does. It keeps your user's session from being trivially stolen. In practise this makes successfully executing attacks harder. It's not a _nice_ thing to have, it's essential. An example of this is an application that asks you to confirm <action> after a POST or w/e. If your XSS vector is not in the new page, then you can't execute <action> as an attacker automatically. Many, many, applications (not only on the web) implement such a scheme. A stolen session is MUCH more valuable to an attacker than only a raw XSS.
mwpmaybe 10y ago
> In my opinion, it is MUCH easier to get a CSRF vulnerability It's simple (though perhaps non-trivial) to protect against XSRF these days, especially if you're securing a JSON API, with: 1. the SameSite cookie option (Chrome-only for now) 2. double submit cookies (mentioned in the article) 3. filtering by the Accept request header, i.e. blacklist application/x-www-form-urlencoded, multipart/form-data, and text/plain, or whitelist application/json (protects against non-XHR, form-based attacks; only appropriate for JSON APIs) 4. CORS, i.e. disallow cross-origin requests, which is the default when no Access-Control-Allow-Origin response header is present (protects against XHR attacks; only appropriate for JSON APIs)
tracker1 10y ago
To your last point, if you want to be able to expire "other" tokens for a user on, for example a password change, then you need to check/verify the token against a datastore on each request anyway... the same will go for access/api throttling. Which will negate some of the enhancements that "stateless" JWT gives you, as it's no longer stateless. Of course, you can selectively "verify" the token, only doing signature validation for most requests (semi-public, browse, ...), but security-sensitive requests validate the token hasn't been revoked (checkout, profile mgt, etc), or is otherwise still valid.
slapresta 10y ago
The crucial point is that XSS vulnerabilities are an application level issue. If you have an XSS vulnerability, your application is broken. Good development practices prevent XSS vulnerabilities. Your application does not have a CSRF vulnerability; HTTP cookies have a CSRF vulnerability. Your application may depend on HTTP cookies, which exposes this vulnerability through your application. The so-called "CSRF protection" is a hack that patches a protocol vulnerability at the application level.

joepie91_ 10y ago

CSRF vulnerabilities are less severe than a stolen session. I've addressed the reason for that here: https://www.reddit.com/r/PHP/comments/4nwpvg/stop_using_jwt_for_sessions/d47larg https://www.reddit.com/r/PHP/comments/4nwpvg/stop_using_jwt_... > This is only true if you are using cookie headers to send the token (which is less common), not if you only use it for storage/retrieval of the token. That's the normal mode of operation for cookies, and what you should assume the client to do. > Lastly, he argues JSON web tokens are not easier to use, but then points out you need a dedicated Redis session store server to scale session authentications. At a scale where you can't just store the sessions in the database you're already using (or on disk - see PHP), the added complexity of a single Redis server is negligible. Below that scale, you can just use your regular database, at no additional complexity cost. > Managing sessions in mobile apps and command line apps is a huge pain compared to JWTs. I've heard a few people claim this now, but none have been able to explain exactly how it's a "huge pain" or "more complex". Care to elaborate?

SCHiM 10y ago

I've tested many web applications, and around 80% of all applications I've tested contained an XSS of some sort or another, that number drops to around 40% if you only look at stored XSS & XSS in a get request. And to less than 10% when only looking at stored XSS. Unless you've used cookies with the HttpOnly flag XSS trivially escalates to session stealing. Do NOT store sessions in anything other than cookies with the HttpOnly (and really, SecureFlag) flag set. Using javascript to manage your sessions only the client side in any way is NOT secure.

mwpmaybe 10y ago
> Using javascript to manage your sessions only the client side in any way is NOT secure. And yet it's common practice, at least in the SPA communities with which I engage on a regular basis.
jupenur 10y ago
> Unless you've used cookies with the HttpOnly flag XSS trivially escalates to session stealing Then again you could just use CSP and mitigate almost 100% of those XSS cases. Yes, even most of the stored ones. And with JWT + JavaScript you don't have to worry about all the oddities in the way cookies work, which is a huge plus.
- mwpmaybe 10y ago
  CSP isn't a silver bullet.
  - seangrogg 10y ago
    Nor is HttpOnly, really.
    - mwpmaybe 10y ago
      I never said it was.
merb 10y ago
if you are vulnerable to XSS your HttpOnly cookie won't help you.
- SCHiM 10y ago
  You are wrong. It does. It keeps your user's session from being trivially stolen. In practise this makes successfully executing attacks harder. It's not a _nice_ thing to have, it's essential. An example of this is an application that asks you to confirm <action> after a POST or w/e. If your XSS vector is not in the new page, then you can't execute <action> as an attacker automatically. Many, many, applications (not only on the web) implement such a scheme. A stolen session is MUCH more valuable to an attacker than only a raw XSS.

mwpmaybe 10y ago

> In my opinion, it is MUCH easier to get a CSRF vulnerability It's simple (though perhaps non-trivial) to protect against XSRF these days, especially if you're securing a JSON API, with: 1. the SameSite cookie option (Chrome-only for now) 2. double submit cookies (mentioned in the article) 3. filtering by the Accept request header, i.e. blacklist application/x-www-form-urlencoded, multipart/form-data, and text/plain, or whitelist application/json (protects against non-XHR, form-based attacks; only appropriate for JSON APIs) 4. CORS, i.e. disallow cross-origin requests, which is the default when no Access-Control-Allow-Origin response header is present (protects against XHR attacks; only appropriate for JSON APIs)

tracker1 10y ago

To your last point, if you want to be able to expire "other" tokens for a user on, for example a password change, then you need to check/verify the token against a datastore on each request anyway... the same will go for access/api throttling. Which will negate some of the enhancements that "stateless" JWT gives you, as it's no longer stateless. Of course, you can selectively "verify" the token, only doing signature validation for most requests (semi-public, browse, ...), but security-sensitive requests validate the token hasn't been revoked (checkout, profile mgt, etc), or is otherwise still valid.

slapresta 10y ago

The crucial point is that XSS vulnerabilities are an application level issue. If you have an XSS vulnerability, your application is broken. Good development practices prevent XSS vulnerabilities. Your application does not have a CSRF vulnerability; HTTP cookies have a CSRF vulnerability. Your application may depend on HTTP cookies, which exposes this vulnerability through your application. The so-called "CSRF protection" is a hack that patches a protocol vulnerability at the application level.