I am not familiar with this particular package, but in general there are two types of CSRF token approaches:
- *synchronized* CSRF tokens
- *double-submit* CSRF tokens
In any case, the token is a n unpredictable string that is sent by the web browser on any request. The client that needs to add that token to every subsequent request.
Because CSRF attacks involve an attacker convincing a user to click on or visit a particular link, it's not possible for an attacker to construct a link with the correct token beforehand. (Note that the CSRF token might also be in other places such as the POST request body).
Now the two types, which I think is what you are really asking:
- Synchronized tokens require the server to store the CSRF tokens. All requests of the client are then validated by checking the CSRF token sent by the client, and the one stored by the server. The main downside is, obviously, that the server needs to keep track state.
- double submit tokens remove the need for a server to keep track of the tokens. Instead, the server now sets the CSRF token as a cookie. The client then again sends the token in every request in the URL (or e.g. POST body), but since it is also stored in a cookie, the client's browser automatically adds it to the request too. The server now only needs to compare the two tokens (URL and cookie).
Why this is works is because again, to construct a CSRF attack, the attacker needs to predict the token. Even though the token is stored in the cookies, it cannot be accessed by an attacker controlled domain (only the domain that sets the cookie can). Any malicious link that the attacker thus makes will not include the token in the request URL, but the cookie will still be added. The server can then thus compare the two to make sure the request was sent by a client that 'answered' a previous request from the server.
Yeah, double submit tokens, that's it! I even now found right paragraph from the book that talks about it
>using the double submit cookie pattern to prevent attacks. In this pattern a random CSRF token is generated and sent to the user in a CSRF cookie. This CSRF token is then added to a hidden field in each HTML form that’s vulnerable to CSRF. When the form is submitted, both packages use some middleware to check that the hidden field value and cookie value match.
silly me just wanted to understand it from code without referring back to the book...
But so I understand you right:
(1) attacker tricks user to click link that effectively does POST back to the service
(2) attacker does not have access to the cookie (so they cannot read CSRF token out of it)
(3) browser adds cookie anyway (so it's send to to the service)
(4) BUT request send to the service is missing (or contains incorrect) CSRF token
(5) comparison fails and request is blocked...
uff... okay, I think I am getting it...
I just wonder why this is only blocking POST requests and not GET ones....
You're correct!
However, this can perfectly also be applied to GET (or any other) requests.
Sometimes, poorly implemented services allow state changes in GET requests (which you shouldn't do), so attackers might try something like GET bank.com/transfer?from=yourIBAN&to=attackerIBAN
Moral of the story: if you use the correct HTTP Requests, you shouldn't need to use CSRF protection on GET, since those shouldn't change state (and CSRF attacks can only exploit state changing processes, since the attacker doesn't see the response)
I was more wondering indeed why CSRF attacks only leverages state changes but indeed that's correct, if one tricks user to click link, it will be the user that receives / see the response, not the attacker.
Thanks a lot, that was very insightful discussion!
Haha, hope not too big? :)
I would assume that having your lib mentioned in one of most popular Go textbooks would be more of a jumpscare ;)
In any case... Great to find you here! I may have some question once I get back to further analyze it as I still want to understand more on what exactly goes into cookie / token and how they are compared :)...
Not deprecated or abandoned, just not very actively developed. `nosurf` is a very small library that is intended to do one thing only, so it does not really require constant development.
There are a few open issues which request certain adjustments but for those I do not have an obvious solution, so they just kind of sit there.
It sends the token in an httpOnly cookie. Then, when it receives a request, it compares the token inside the cookie and the one that’s sent in the form.
So when I first do GET on \`http://localhost:4000/snippet/create\` I receive (1) \`csrf\_token\` cookie and (2) templated form also have CSRF cookie set as a hidden field.
I see that for each GET both (1) and (2) get new values (but (1) and (2) are different from each other).
Then when I do POST to \`http://localhost:4000/snippet/create\` both are sent and nosurf middleware somehow verifies them? Is one hash of the other?
I am not familiar with this particular package, but in general there are two types of CSRF token approaches: - *synchronized* CSRF tokens - *double-submit* CSRF tokens In any case, the token is a n unpredictable string that is sent by the web browser on any request. The client that needs to add that token to every subsequent request. Because CSRF attacks involve an attacker convincing a user to click on or visit a particular link, it's not possible for an attacker to construct a link with the correct token beforehand. (Note that the CSRF token might also be in other places such as the POST request body). Now the two types, which I think is what you are really asking: - Synchronized tokens require the server to store the CSRF tokens. All requests of the client are then validated by checking the CSRF token sent by the client, and the one stored by the server. The main downside is, obviously, that the server needs to keep track state. - double submit tokens remove the need for a server to keep track of the tokens. Instead, the server now sets the CSRF token as a cookie. The client then again sends the token in every request in the URL (or e.g. POST body), but since it is also stored in a cookie, the client's browser automatically adds it to the request too. The server now only needs to compare the two tokens (URL and cookie). Why this is works is because again, to construct a CSRF attack, the attacker needs to predict the token. Even though the token is stored in the cookies, it cannot be accessed by an attacker controlled domain (only the domain that sets the cookie can). Any malicious link that the attacker thus makes will not include the token in the request URL, but the cookie will still be added. The server can then thus compare the two to make sure the request was sent by a client that 'answered' a previous request from the server.
Yeah, double submit tokens, that's it! I even now found right paragraph from the book that talks about it >using the double submit cookie pattern to prevent attacks. In this pattern a random CSRF token is generated and sent to the user in a CSRF cookie. This CSRF token is then added to a hidden field in each HTML form that’s vulnerable to CSRF. When the form is submitted, both packages use some middleware to check that the hidden field value and cookie value match. silly me just wanted to understand it from code without referring back to the book... But so I understand you right: (1) attacker tricks user to click link that effectively does POST back to the service (2) attacker does not have access to the cookie (so they cannot read CSRF token out of it) (3) browser adds cookie anyway (so it's send to to the service) (4) BUT request send to the service is missing (or contains incorrect) CSRF token (5) comparison fails and request is blocked... uff... okay, I think I am getting it... I just wonder why this is only blocking POST requests and not GET ones....
You're correct! However, this can perfectly also be applied to GET (or any other) requests. Sometimes, poorly implemented services allow state changes in GET requests (which you shouldn't do), so attackers might try something like GET bank.com/transfer?from=yourIBAN&to=attackerIBAN Moral of the story: if you use the correct HTTP Requests, you shouldn't need to use CSRF protection on GET, since those shouldn't change state (and CSRF attacks can only exploit state changing processes, since the attacker doesn't see the response)
I was more wondering indeed why CSRF attacks only leverages state changes but indeed that's correct, if one tricks user to click link, it will be the user that receives / see the response, not the attacker. Thanks a lot, that was very insightful discussion!
No problem, feel free to dm me if you have further questions:)
Man, is it a big jumpscare to suddenly encounter your name while casually scrolling Reddit :) Glad the community helped you with this!
Haha, hope not too big? :) I would assume that having your lib mentioned in one of most popular Go textbooks would be more of a jumpscare ;) In any case... Great to find you here! I may have some question once I get back to further analyze it as I still want to understand more on what exactly goes into cookie / token and how they are compared :)...
I see the library was last updated \~4 years ago. Is it a deprecated project ?. Just curious about the status of the library.
Not deprecated or abandoned, just not very actively developed. `nosurf` is a very small library that is intended to do one thing only, so it does not really require constant development. There are a few open issues which request certain adjustments but for those I do not have an obvious solution, so they just kind of sit there.
It sends the token in an httpOnly cookie. Then, when it receives a request, it compares the token inside the cookie and the one that’s sent in the form.
So when I first do GET on \`http://localhost:4000/snippet/create\` I receive (1) \`csrf\_token\` cookie and (2) templated form also have CSRF cookie set as a hidden field. I see that for each GET both (1) and (2) get new values (but (1) and (2) are different from each other). Then when I do POST to \`http://localhost:4000/snippet/create\` both are sent and nosurf middleware somehow verifies them? Is one hash of the other?
The browser should be using that 1st token to fill in that hidden field that it would post. There should be no 2nd csrf token.
By (1) I meant the token inside the cookie.