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 2 days ago
MeanGreenMeanGreen
24125
New contributor
MeanGreen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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 2 days ago
MeanGreenMeanGreen
24125
New contributor
MeanGreen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
You might want to look at the more recently introducedSameSiteflag for cookies as well as (part of) your protection against CSRF.
– caw
yesterday
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 2 days ago
MeanGreenMeanGreen
24125
New contributor
MeanGreen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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 2 days ago
MeanGreenMeanGreen
24125
New contributor
MeanGreen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 2 days ago
MeanGreenMeanGreen
24125
New contributor
MeanGreen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 2 days ago
MeanGreenMeanGreen
24125
New contributor
MeanGreen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 2 days ago
MeanGreenMeanGreen
24125
asked 2 days ago
MeanGreenMeanGreen
24125
24125
New contributor
MeanGreen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
MeanGreen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
MeanGreen is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
You might want to look at the more recently introducedSameSiteflag for cookies as well as (part of) your protection against CSRF.
– caw
yesterday
add a comment |
You might want to look at the more recently introducedSameSiteflag for cookies as well as (part of) your protection against CSRF.
– caw
yesterday
You might want to look at the more recently introduced
SameSite flag for cookies as well as (part of) your protection against CSRF.– caw
yesterday
You might want to look at the more recently introduced
SameSite flag for cookies as well as (part of) your protection against CSRF.– caw
yesterday
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 2 days ago
Mike OunsworthMike Ounsworth
39.3k1593139
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
2 days ago
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
2 days ago
2
@Yay295 How so?
– Mike Ounsworth
2 days ago
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
2 days ago
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
2 days ago
|
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
});
}
});
MeanGreen is a new contributor. Be nice, and check out our Code of Conduct.
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 2 days ago
Mike OunsworthMike Ounsworth
39.3k1593139
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
2 days ago
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
2 days ago
2
@Yay295 How so?
– Mike Ounsworth
2 days ago
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
2 days ago
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
2 days ago
|
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 2 days ago
Mike OunsworthMike Ounsworth
39.3k1593139
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
2 days ago
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
2 days ago
2
@Yay295 How so?
– Mike Ounsworth
2 days ago
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
2 days ago
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
2 days ago
|
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 2 days ago
Mike OunsworthMike Ounsworth
39.3k1593139
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 2 days ago
Mike OunsworthMike Ounsworth
39.3k1593139
edited 2 days ago
answered 2 days ago
Mike OunsworthMike Ounsworth
39.3k1593139
answered 2 days ago
Mike OunsworthMike Ounsworth
39.3k1593139
answered 2 days ago
Mike OunsworthMike Ounsworth
39.3k1593139
39.3k1593139
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
2 days ago
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
2 days ago
2
@Yay295 How so?
– Mike Ounsworth
2 days ago
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
2 days ago
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
2 days ago
|
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
2 days ago
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
2 days ago
2
@Yay295 How so?
– Mike Ounsworth
2 days ago
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
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
2 days ago
2
2
@Yay295 How so?
– Mike Ounsworth
2 days ago
@Yay295 How so?
– Mike Ounsworth
2 days ago
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
2 days ago
If it's just somewhere on the page, any script running on the page will be able to see it.
– Yay295
2 days ago
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
2 days ago
@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
2 days ago
|
show 3 more comments
MeanGreen is a new contributor. Be nice, and check out our Code of Conduct.
MeanGreen is a new contributor. Be nice, and check out our Code of Conduct.
MeanGreen is a new contributor. Be nice, and check out our Code of Conduct.
MeanGreen is a new contributor. Be nice, and check out our Code of Conduct.
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
You might want to look at the more recently introduced
SameSiteflag for cookies as well as (part of) your protection against CSRF.– caw
yesterday