oh god you're right https://stackoverflow.com/a/57206146/1685746 yeah sure what can go wrong, let's listen to fetch and modify requests in a service worker.

I actually use this to add authentication headers to images directly via src="". No blob management in javascript :)

I asked that in the post but nobody answered still, let's try here.

Why are CSRF tokens rotated? OWASP says it's somehow more secure but I don't really see why.

mitm means you can control users network, doesn't it?

Another question, does this work with https?

And the third one, if this was the thing some dishonest governments or vpn providers would do this already. Would be cool to read on that (genuinely, not implying this never happened)

> mitm means you can control users network, doesn't it?

Not necessarily. Maybe this is not called MITM, but you have to put something in the middle :)

> Another question, does this work with https?

Sure.

> And the third one, if this was the thing some dishonest governments or vpn providers would do this already.

You are confused what this attack is about. Say I want to embed some widget on my website by which I can receive payments. I have to register my websites domain (technically protocol+domain(+port), aka origin) with the widget's provider. CORS is then used to make sure no-one can embed the widget, but those with registered origins.

Only browsers are known to enforce CORS (do the checks AND provide the correct origin when doing the checks). Hence the MITM attack I propose works: the MITM does NOT give the correct origin to the real server.

> How does server know the cookie is valid if it doesn't store it

depending on why you'are asking the question, * because it decrypts correctly * because it contains some user identifier

People don't usually store sessions in cookies because cookies can't be very big, and session do become big. So what people do instead they store cookies in databases, and put session identifiers into cookies.

You don't need to store CSRF in sessions. Django doesn't by default.

CSRF token can be entirely separate from sessions.

not even you don't need to, you shouldn't. Sessions shouldn't be accessible to js at all

Why would you need that?

Also, one thing I can speculate that phishing would become even easier if such things were allowed

Because defaulting to NOT allowing cross-origin requests made it so that being lazy creates a more closed web. And people are lazy.

This is my blog. I haven't posted all the articles from there to hackernews. I think some of them are not worth discussing because too old or too poorly written, but some are just not posted because I didn't think of it at the time. Thanks for the interest, I will re-read what I wrote and post some.

it is true. But again, writes are allowed, reads are not, you won't be able to see the reply. Which author of the question eventually realised https://stackoverflow.com/a/44122076/1685746

well it does make sense to assume that by default different origins belong to different people, and some of those people don't have to behave friendly to each other.

There is little server can do with that, because of the request-based model. The state that persists between requests lives in cookies, and it's browser job not to expose those cookies all around. Turning off single origin policy would be a terrible idea. For one, it makes CSRF work by not allowing cross-origin reads.

yup. You didn't imply it but just in case -- this token shouldn't be the same as session token. Session tokens should be `HttpOnly`, so that we don't even expose it to javascript

The HttpOnly flag isn't really practical in modern web apps where so much logic runs in JS in the browser and makes requests to APIs. It's a leftover from an earlier era of web app architecture.

If it can be enabled without breaking something, sure, its a good idea, but unless your app is 2000s-era ASP.NET code or CGI script, preventing browser-side JS from accessing the session token will probably break something.

Right, but if you're doing a SPA, your SPA makes the login call and stores a copy of the session token in local storage, which unlike a cookie isn't automatically sent on any request, never mind cross-origin ones. Doesn't prevent against XSS of course, but then that's what CSP is for.

It's only necessary to store the login token if your backend is on a different origin than your SPA is served from. It's not especially hard to avoid this.

You shouldn't need your session token in JS, you can specify your fetch requests to include cookies, and you can setup CORS to allow that.

oh hell yes. And oh yes iframes and postmessages, of course people would setup them incorrectly and even if they do some (probably not that important but still) data will leak if you're creative enough. Thanks for the link!