Hacker News Reader

Comment by chuckadams | Hacker News Reader

> It seems like the problem is at the level of login information somehow crossing domain boundaries?

The login information isn't so much crossing boundaries -- evil.com can't read your session cookie on bank.com -- but cookies that don't set a SameSite attribute allow anyone to send that information on your behalf, and effectively act as you in that request. Textbook example of a "confused deputy" attack.

> What stops a script on evil.com from going to bank.com to get a CSRF token and then including that in their evil request?

The token is either stored on the page that bank.com sends (for a html form) or was sent in a header and stored in local storage (for API clients). In neither case can evil.com read that information, due to cross-origin restrictions, and it changes with every form.

View on HN

> In neither case can evil.com read that information

What stops evil.com from having an API endpoint called evil.com/returnBankCSRFToken that goes to bank.com, scrapes token and returns it?

CSRF tokens are just part of an html form - they are not hidden or obscured and thus scraping them is trivial.

When I go to evil.com, it calls the endpoint, gets token and sends a request to bank.com using said token, thus bypassing CSRF?

Nothing stops, but it will be a different CSRF token, which will not match to the one generated for the original page.

Server keeps track of which CSRF token is given to which client using cookies (usually some form of SessionID), and stores it on the server somewhere.

It is a very common pattern and all frameworks support it with the concept of "sessions" on the back end.

> stores it on the server somewhere

you don't need to store anything on the server. cookies for that domain are sent with the request and it is enough for the server to check its cookie with the csrf request data.

browsers would send the bank.com cookies with the bank.com request. It is security built into the browser which is why its so important to use secure browsers and secure cookies.

If the malicious user convinces the user to use an insecure browser you can circumvent CSRF, but at that point there are probably other exploits you can do.

How does server know the cookie is valid if it doesn't store it and how does it know csrf token is valid if it doesn't store it and finally how does it know that this csrf token relates to this cookie session token if it doesn't store it?

The CSRF token can have nothing to do with the cookie session information. you can store CSRF as a separate cookie.

You can validate the CSRF is valid by keeping a key on your server and matching that the token you get can be derived from that key.

See Django's implementation of CSRF for more details. CSRF tokens are separate from session and no CSRF information needs to be stored in database to validate CSRF.

> 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

> What stops evil.com from having an API endpoint called evil.com/returnBankCSRFToken that goes to bank.com, scrapes token and returns it?

so evil.com will now require some sort of authentication mechanism with bank.com to scrape a valid CSRF token. If this authentication works (either if the user willingly gave their login information to evil.com, or they have a deal with bank.com directly), then there's no issues, and it works as expected.

Reply on news.ycombinator.com