Is the core idea behind CSRF protection that the hacker doesn't know the token value?
I'm trying to fully understand the concept behind CSRF, and more importantly, how to protect against it.
Can I assume, using only CSRF, so no XSS or other techniques, a hacker cannot know the value of the random anti-CSRF token I insert into the page?
web-application csrf
asked Jan 17 at 14:50
MeanGreenMeanGreen
24625
add a comment |
I'm trying to fully understand the concept behind CSRF, and more importantly, how to protect against it.
Can I assume, using only CSRF, so no XSS or other techniques, a hacker cannot know the value of the random anti-CSRF token I insert into the page?
web-application csrf
asked Jan 17 at 14:50
MeanGreenMeanGreen
24625
2
You might want to look at the more recently introducedSameSiteflag for cookies as well as (part of) your protection against CSRF.
– caw
Jan 18 at 17:03
add a comment |
I'm trying to fully understand the concept behind CSRF, and more importantly, how to protect against it.
Can I assume, using only CSRF, so no XSS or other techniques, a hacker cannot know the value of the random anti-CSRF token I insert into the page?
web-application csrf
asked Jan 17 at 14:50
MeanGreenMeanGreen
24625
I'm trying to fully understand the concept behind CSRF, and more importantly, how to protect against it.
Can I assume, using only CSRF, so no XSS or other techniques, a hacker cannot know the value of the random anti-CSRF token I insert into the page?
web-application csrf
web-application csrf
asked Jan 17 at 14:50
MeanGreenMeanGreen
24625
asked Jan 17 at 14:50
MeanGreenMeanGreen
24625
asked Jan 17 at 14:50
MeanGreenMeanGreen
24625
asked Jan 17 at 14:50
MeanGreenMeanGreen
24625
asked Jan 17 at 14:50
MeanGreenMeanGreen
24625
24625
2
You might want to look at the more recently introducedSameSiteflag for cookies as well as (part of) your protection against CSRF.
– caw
Jan 18 at 17:03
add a comment |
2
You might want to look at the more recently introducedSameSiteflag for cookies as well as (part of) your protection against CSRF.
– caw
Jan 18 at 17:03
2
2
You might want to look at the more recently introduced
SameSite flag for cookies as well as (part of) your protection against CSRF.– caw
Jan 18 at 17:03
You might want to look at the more recently introduced
SameSite flag for cookies as well as (part of) your protection against CSRF.– caw
Jan 18 at 17:03
add a comment |
1 Answer
1
active
oldest
votes
Your understanding is correct.
Background
The simplest way to think of a CSRF attack is that your browser has two tabs open - Tab A: www.mybank.com and Tab B: www.attacker.com.
(As @Alex points out in comments, multiple tabs are not necessary; the important part is that your browser has auth cookies for mybank.com in memory. CSRF can equally happen if you were on mybank.com earlier and then without logging out, browse to attacker.com)
Cookies
Historically, it was common to store your auth / session token in a cookie. This is convenient for pure HTML pages (ie no javascript) because when you send a request to www.mybank.com, the browser will automatically attach any relevant auth cookies -- no action required on the part of your HTML page in order to maintain the session. CSRF is an attack on cookie-based auth tokens: if Tab B (www.attacker.com) sends a request to www.mybank.com, the browser will automatically attach the authentication cookie, ie Tab B can send requests as if they were logged in to Tab A.
Solutions
You need to put your auth / session token somewhere that's not a cookie. Remembering that Tab B can't see any of the content in Tab A, there are any number of places you could put the auth / session token:
- somewhere on the HTML page (maybe in a hidden HTML element),
- or in a non-cookie HTTP Response Header,
- or if this is an API then you could put it in a
token: ___field of the JSON body, etc.
It really doesn't matter where, so long as it's not in a cookie.
For completeness, I'll add that your anti-CSRF token needs to be long and random enough to prevent the attacker from guessing it. For example, if you use the same anti-CSRF token for all users, or you derive it from the user name, then it doesn't matter that Tab B can't read the content of Tab A because they can guess the token and include it in their blind CSRF request.
References
- OWASP Cross-Site Request Forgery (CSRF)
- OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
answered Jan 17 at 15:14
Mike OunsworthMike Ounsworth
39.4k1593140
6
As an example, I worked on a project where the CSRF token was accidentally being set to a simple timestamp of the request. To a layperson, it looked like a random long number, but to a hacker or developer, it was immediately clear that it was not random at all and simply a millisecond timestamp. That would be easy to guess for an attacker, so a pretty pointless implementation. In other words, it seems dumb to use the same token for every user, but when you see a real mistake like this, you realize that it does happen from time to time.
– JPhi1618
Jan 17 at 19:54
somewhere on the HTML page (maybe in a hidden HTML element)Doesn't sound very safe to me. It prevents CSRF, but makes you vulnerable to XSS.
– Yay295
Jan 18 at 2:56
2
@Yay295 How so?
– Mike Ounsworth
Jan 18 at 2:58
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
Jan 18 at 3:03
5
@Yay295 Exactly, that's the whole point of a CSRF token, the server hands it to the page (and any scripts running on it) so that they can hand it back with the next request. I don't see the problem...?
– Mike Ounsworth
Jan 18 at 3:06
|
show 3 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201657%2fis-the-core-idea-behind-csrf-protection-that-the-hacker-doesnt-know-the-token-v%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Your understanding is correct.
Background
The simplest way to think of a CSRF attack is that your browser has two tabs open - Tab A: www.mybank.com and Tab B: www.attacker.com.
(As @Alex points out in comments, multiple tabs are not necessary; the important part is that your browser has auth cookies for mybank.com in memory. CSRF can equally happen if you were on mybank.com earlier and then without logging out, browse to attacker.com)
Cookies
Historically, it was common to store your auth / session token in a cookie. This is convenient for pure HTML pages (ie no javascript) because when you send a request to www.mybank.com, the browser will automatically attach any relevant auth cookies -- no action required on the part of your HTML page in order to maintain the session. CSRF is an attack on cookie-based auth tokens: if Tab B (www.attacker.com) sends a request to www.mybank.com, the browser will automatically attach the authentication cookie, ie Tab B can send requests as if they were logged in to Tab A.
Solutions
You need to put your auth / session token somewhere that's not a cookie. Remembering that Tab B can't see any of the content in Tab A, there are any number of places you could put the auth / session token:
- somewhere on the HTML page (maybe in a hidden HTML element),
- or in a non-cookie HTTP Response Header,
- or if this is an API then you could put it in a
token: ___field of the JSON body, etc.
It really doesn't matter where, so long as it's not in a cookie.
For completeness, I'll add that your anti-CSRF token needs to be long and random enough to prevent the attacker from guessing it. For example, if you use the same anti-CSRF token for all users, or you derive it from the user name, then it doesn't matter that Tab B can't read the content of Tab A because they can guess the token and include it in their blind CSRF request.
References
- OWASP Cross-Site Request Forgery (CSRF)
- OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
answered Jan 17 at 15:14
Mike OunsworthMike Ounsworth
39.4k1593140
6
As an example, I worked on a project where the CSRF token was accidentally being set to a simple timestamp of the request. To a layperson, it looked like a random long number, but to a hacker or developer, it was immediately clear that it was not random at all and simply a millisecond timestamp. That would be easy to guess for an attacker, so a pretty pointless implementation. In other words, it seems dumb to use the same token for every user, but when you see a real mistake like this, you realize that it does happen from time to time.
– JPhi1618
Jan 17 at 19:54
somewhere on the HTML page (maybe in a hidden HTML element)Doesn't sound very safe to me. It prevents CSRF, but makes you vulnerable to XSS.
– Yay295
Jan 18 at 2:56
2
@Yay295 How so?
– Mike Ounsworth
Jan 18 at 2:58
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
Jan 18 at 3:03
5
@Yay295 Exactly, that's the whole point of a CSRF token, the server hands it to the page (and any scripts running on it) so that they can hand it back with the next request. I don't see the problem...?
– Mike Ounsworth
Jan 18 at 3:06
|
show 3 more comments
Your understanding is correct.
Background
The simplest way to think of a CSRF attack is that your browser has two tabs open - Tab A: www.mybank.com and Tab B: www.attacker.com.
(As @Alex points out in comments, multiple tabs are not necessary; the important part is that your browser has auth cookies for mybank.com in memory. CSRF can equally happen if you were on mybank.com earlier and then without logging out, browse to attacker.com)
Cookies
Historically, it was common to store your auth / session token in a cookie. This is convenient for pure HTML pages (ie no javascript) because when you send a request to www.mybank.com, the browser will automatically attach any relevant auth cookies -- no action required on the part of your HTML page in order to maintain the session. CSRF is an attack on cookie-based auth tokens: if Tab B (www.attacker.com) sends a request to www.mybank.com, the browser will automatically attach the authentication cookie, ie Tab B can send requests as if they were logged in to Tab A.
Solutions
You need to put your auth / session token somewhere that's not a cookie. Remembering that Tab B can't see any of the content in Tab A, there are any number of places you could put the auth / session token:
- somewhere on the HTML page (maybe in a hidden HTML element),
- or in a non-cookie HTTP Response Header,
- or if this is an API then you could put it in a
token: ___field of the JSON body, etc.
It really doesn't matter where, so long as it's not in a cookie.
For completeness, I'll add that your anti-CSRF token needs to be long and random enough to prevent the attacker from guessing it. For example, if you use the same anti-CSRF token for all users, or you derive it from the user name, then it doesn't matter that Tab B can't read the content of Tab A because they can guess the token and include it in their blind CSRF request.
References
- OWASP Cross-Site Request Forgery (CSRF)
- OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
answered Jan 17 at 15:14
Mike OunsworthMike Ounsworth
39.4k1593140
6
As an example, I worked on a project where the CSRF token was accidentally being set to a simple timestamp of the request. To a layperson, it looked like a random long number, but to a hacker or developer, it was immediately clear that it was not random at all and simply a millisecond timestamp. That would be easy to guess for an attacker, so a pretty pointless implementation. In other words, it seems dumb to use the same token for every user, but when you see a real mistake like this, you realize that it does happen from time to time.
– JPhi1618
Jan 17 at 19:54
somewhere on the HTML page (maybe in a hidden HTML element)Doesn't sound very safe to me. It prevents CSRF, but makes you vulnerable to XSS.
– Yay295
Jan 18 at 2:56
2
@Yay295 How so?
– Mike Ounsworth
Jan 18 at 2:58
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
Jan 18 at 3:03
5
@Yay295 Exactly, that's the whole point of a CSRF token, the server hands it to the page (and any scripts running on it) so that they can hand it back with the next request. I don't see the problem...?
– Mike Ounsworth
Jan 18 at 3:06
|
show 3 more comments
Your understanding is correct.
Background
The simplest way to think of a CSRF attack is that your browser has two tabs open - Tab A: www.mybank.com and Tab B: www.attacker.com.
(As @Alex points out in comments, multiple tabs are not necessary; the important part is that your browser has auth cookies for mybank.com in memory. CSRF can equally happen if you were on mybank.com earlier and then without logging out, browse to attacker.com)
Cookies
Historically, it was common to store your auth / session token in a cookie. This is convenient for pure HTML pages (ie no javascript) because when you send a request to www.mybank.com, the browser will automatically attach any relevant auth cookies -- no action required on the part of your HTML page in order to maintain the session. CSRF is an attack on cookie-based auth tokens: if Tab B (www.attacker.com) sends a request to www.mybank.com, the browser will automatically attach the authentication cookie, ie Tab B can send requests as if they were logged in to Tab A.
Solutions
You need to put your auth / session token somewhere that's not a cookie. Remembering that Tab B can't see any of the content in Tab A, there are any number of places you could put the auth / session token:
- somewhere on the HTML page (maybe in a hidden HTML element),
- or in a non-cookie HTTP Response Header,
- or if this is an API then you could put it in a
token: ___field of the JSON body, etc.
It really doesn't matter where, so long as it's not in a cookie.
For completeness, I'll add that your anti-CSRF token needs to be long and random enough to prevent the attacker from guessing it. For example, if you use the same anti-CSRF token for all users, or you derive it from the user name, then it doesn't matter that Tab B can't read the content of Tab A because they can guess the token and include it in their blind CSRF request.
References
- OWASP Cross-Site Request Forgery (CSRF)
- OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
answered Jan 17 at 15:14
Mike OunsworthMike Ounsworth
39.4k1593140
Your understanding is correct.
Background
The simplest way to think of a CSRF attack is that your browser has two tabs open - Tab A: www.mybank.com and Tab B: www.attacker.com.
(As @Alex points out in comments, multiple tabs are not necessary; the important part is that your browser has auth cookies for mybank.com in memory. CSRF can equally happen if you were on mybank.com earlier and then without logging out, browse to attacker.com)
Cookies
Historically, it was common to store your auth / session token in a cookie. This is convenient for pure HTML pages (ie no javascript) because when you send a request to www.mybank.com, the browser will automatically attach any relevant auth cookies -- no action required on the part of your HTML page in order to maintain the session. CSRF is an attack on cookie-based auth tokens: if Tab B (www.attacker.com) sends a request to www.mybank.com, the browser will automatically attach the authentication cookie, ie Tab B can send requests as if they were logged in to Tab A.
Solutions
You need to put your auth / session token somewhere that's not a cookie. Remembering that Tab B can't see any of the content in Tab A, there are any number of places you could put the auth / session token:
- somewhere on the HTML page (maybe in a hidden HTML element),
- or in a non-cookie HTTP Response Header,
- or if this is an API then you could put it in a
token: ___field of the JSON body, etc.
It really doesn't matter where, so long as it's not in a cookie.
For completeness, I'll add that your anti-CSRF token needs to be long and random enough to prevent the attacker from guessing it. For example, if you use the same anti-CSRF token for all users, or you derive it from the user name, then it doesn't matter that Tab B can't read the content of Tab A because they can guess the token and include it in their blind CSRF request.
References
- OWASP Cross-Site Request Forgery (CSRF)
- OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
answered Jan 17 at 15:14
Mike OunsworthMike Ounsworth
39.4k1593140
edited Jan 17 at 16:07
answered Jan 17 at 15:14
Mike OunsworthMike Ounsworth
39.4k1593140
answered Jan 17 at 15:14
Mike OunsworthMike Ounsworth
39.4k1593140
answered Jan 17 at 15:14
Mike OunsworthMike Ounsworth
39.4k1593140
39.4k1593140
6
As an example, I worked on a project where the CSRF token was accidentally being set to a simple timestamp of the request. To a layperson, it looked like a random long number, but to a hacker or developer, it was immediately clear that it was not random at all and simply a millisecond timestamp. That would be easy to guess for an attacker, so a pretty pointless implementation. In other words, it seems dumb to use the same token for every user, but when you see a real mistake like this, you realize that it does happen from time to time.
– JPhi1618
Jan 17 at 19:54
somewhere on the HTML page (maybe in a hidden HTML element)Doesn't sound very safe to me. It prevents CSRF, but makes you vulnerable to XSS.
– Yay295
Jan 18 at 2:56
2
@Yay295 How so?
– Mike Ounsworth
Jan 18 at 2:58
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
Jan 18 at 3:03
5
@Yay295 Exactly, that's the whole point of a CSRF token, the server hands it to the page (and any scripts running on it) so that they can hand it back with the next request. I don't see the problem...?
– Mike Ounsworth
Jan 18 at 3:06
|
show 3 more comments
6
As an example, I worked on a project where the CSRF token was accidentally being set to a simple timestamp of the request. To a layperson, it looked like a random long number, but to a hacker or developer, it was immediately clear that it was not random at all and simply a millisecond timestamp. That would be easy to guess for an attacker, so a pretty pointless implementation. In other words, it seems dumb to use the same token for every user, but when you see a real mistake like this, you realize that it does happen from time to time.
– JPhi1618
Jan 17 at 19:54
somewhere on the HTML page (maybe in a hidden HTML element)Doesn't sound very safe to me. It prevents CSRF, but makes you vulnerable to XSS.
– Yay295
Jan 18 at 2:56
2
@Yay295 How so?
– Mike Ounsworth
Jan 18 at 2:58
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
Jan 18 at 3:03
5
@Yay295 Exactly, that's the whole point of a CSRF token, the server hands it to the page (and any scripts running on it) so that they can hand it back with the next request. I don't see the problem...?
– Mike Ounsworth
Jan 18 at 3:06
6
6
As an example, I worked on a project where the CSRF token was accidentally being set to a simple timestamp of the request. To a layperson, it looked like a random long number, but to a hacker or developer, it was immediately clear that it was not random at all and simply a millisecond timestamp. That would be easy to guess for an attacker, so a pretty pointless implementation. In other words, it seems dumb to use the same token for every user, but when you see a real mistake like this, you realize that it does happen from time to time.
– JPhi1618
Jan 17 at 19:54
As an example, I worked on a project where the CSRF token was accidentally being set to a simple timestamp of the request. To a layperson, it looked like a random long number, but to a hacker or developer, it was immediately clear that it was not random at all and simply a millisecond timestamp. That would be easy to guess for an attacker, so a pretty pointless implementation. In other words, it seems dumb to use the same token for every user, but when you see a real mistake like this, you realize that it does happen from time to time.
– JPhi1618
Jan 17 at 19:54
somewhere on the HTML page (maybe in a hidden HTML element) Doesn't sound very safe to me. It prevents CSRF, but makes you vulnerable to XSS.– Yay295
Jan 18 at 2:56
somewhere on the HTML page (maybe in a hidden HTML element) Doesn't sound very safe to me. It prevents CSRF, but makes you vulnerable to XSS.– Yay295
Jan 18 at 2:56
2
2
@Yay295 How so?
– Mike Ounsworth
Jan 18 at 2:58
@Yay295 How so?
– Mike Ounsworth
Jan 18 at 2:58
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
Jan 18 at 3:03
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
Jan 18 at 3:03
5
5
@Yay295 Exactly, that's the whole point of a CSRF token, the server hands it to the page (and any scripts running on it) so that they can hand it back with the next request. I don't see the problem...?
– Mike Ounsworth
Jan 18 at 3:06
@Yay295 Exactly, that's the whole point of a CSRF token, the server hands it to the page (and any scripts running on it) so that they can hand it back with the next request. I don't see the problem...?
– Mike Ounsworth
Jan 18 at 3:06
|
show 3 more comments
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201657%2fis-the-core-idea-behind-csrf-protection-that-the-hacker-doesnt-know-the-token-v%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
You might want to look at the more recently introduced
SameSiteflag for cookies as well as (part of) your protection against CSRF.– caw
Jan 18 at 17:03