Hacker News Reader

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.

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.

> 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.

CSP isn't a silver bullet.

Nor is HttpOnly, really.

I never said it was.

if you are vulnerable to XSS your HttpOnly cookie won't help you.

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.

It does not. It is the difference between an exploit that yields a root password and one that yields a shell at uid=0.

HttpOnly is almost totally cosmetic.

It's not the same, an XSS is not comparable to a shell for the exact reason I outlined above. And a session is not a password.

I'm probably coming over as too offensive, but you really really don't seem to know what you are even talking about. You are wrong wrong wrong.

If you don't believe `tptacek maybe you will believe James Kettle:

http://blog.portswigger.net/2016/05/web-storage-lesser-evil-...

I'm pretty sure? I do know what I'm talking about here. Sorry. HttpOnly is a joke.

> 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.

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_...

> 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?

> 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)

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.