I hope someone can explain to me in practical terms difference between a session cookie string on a request and a token as header value.

Cookies are just string in a header. The difference is that unlike normal headers browesers treat cookie headers in a special way. They automatically add and remove keys from it, and they allow the server to set the header in a way that the client can neither see it nor change it (http only headers)

The downside being that the browser will attach it to every request; if you use cookies, you MUST be aware of this, or you are (IMO) pretty much guaranteed to write a CSRF vuln.

(I'm much more in the localStorage + Authorization header for this reason. I recommend [1] for reading. If malicious JS is running, cookies won't save you, since the malicious JS is capable of simply making the request itself, to which the cookie will automatically be attached by the browser. localStorage+JS eliminates CSRF. If someone XSS's you, the difference is irrelevant.)

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

> I'm much more in the localStorage + Authorization header for this reason.

That's just exchanging one security issue for another. Now you have the ability for people to steal tokens after an XSS attack. And yes, that's significantly different from "can make requests on your behalf".

The correct solution is to solve the CSRF vulnerabilities by using CSRF tokens. Not to change your auth persistence mechanism.

CSRF protection:

* Use SameSite cookies (unfortunately, not yet supported by all browsers)

* Don't accept application/x-www-form-urlencoded, multipart/form-data, or text/plain at your endpoints, or

* Use CSRF tokens if you need to accept server-side rendered HTML forms

CSRF is the easiest vulnerability to avoid, a csrf token solves all csrf attacks.

XSS is a lot harder to protect against, one of the better ways to mitigate it's effects is to use http only cookies

Well, I keep running into CSRF vulns. in the wild, so…

XSS is avoidable by systematically having a framework that escapes any inputs that are run through it. (jinja2, on the server, can do this, though it defaults to not, which I wish wasn't true.) I'm not saying that XSS is much better that CSRF, really; I've seen these, too.

the point (and that of the linked article) is more that either you're not subject to XSS, in which case localStorage is strictly better than cookies (it is default-secure), or you're subject to XSS, in which case neither saves you.

The idea that Session Hijacking attacks are irrelevant when a user can use XSS to perform any action on the client is interesting.

Definitely if your service is a valuable target that hackers will spend the time to reverse engineer your client code to create custom tailored XSS attacks then protecting against Session Hijacking does seem to be pointless.

But session hijacking is considered to be a very common attack (though I can't find any real numbers anywhere, maybe it's not?), most services with low attack value will probably be better served by httpOnly cookies and csrf tokens that make worthwhile XSS attacks more time consuming then preventing XSS altogether, which is an enormous, continuous effort.

Also your implying that CSRF is hard to defend against (otherwise why do you keep running into it) but in the same breath saying that XSS is simple to defend against.

If people can't defend against CSRF (which is usually just a simple flag for most frameworks), they aren't prepared to defend against XSS which means getting into a security mindset in all things. A serverside template is not enough - XSS can manifest in headers, in clientside code, in third party code, in redirections and it is easy for a developer to mistakingly add a new attack surface.

One small correction: the client (i.e., the web browser or other web client) can see HTTP-only cookies just fine; code running in a conforming browser cannot.

But if I write some code using DRAKMA, urllib or net/http, and can see those cookies just fine.

The very next sentence:

> Although I suppose you could argue that a cookie is just another header value.

So... yes.

Ack - missed that - was visually jumping around some.

But yes, it is.