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 hours ago
MeanGreenMeanGreen
1312
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 hours ago
MeanGreenMeanGreen
1312
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 hours ago
MeanGreenMeanGreen
1312
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 hours ago
MeanGreenMeanGreen
1312
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 hours ago
MeanGreenMeanGreen
1312
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 hours ago
MeanGreenMeanGreen
1312
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 hours ago
MeanGreenMeanGreen
1312
asked 2 hours ago
MeanGreenMeanGreen
1312
1312
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.
add a comment |
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 hours ago
Mike OunsworthMike Ounsworth
39.1k1593138
1
I think you nailed it, just want to clear one thing up because it might be confusing: CSRF does not directly depend on browser tabs. Your browser just need to have a cookie for www.mybank.com stored to make CSRF possible. So, even when you close the tab with mybank.com, the cookie ist still there, so CSRF is still possible.
– Alex
1 hour ago
@Alex Thanks! Is that edit in line with what you were thinking?
– Mike Ounsworth
1 hour ago
yes thats what I was thinking about
– Alex
1 hour ago
add a comment |
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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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 hours ago
Mike OunsworthMike Ounsworth
39.1k1593138
1
I think you nailed it, just want to clear one thing up because it might be confusing: CSRF does not directly depend on browser tabs. Your browser just need to have a cookie for www.mybank.com stored to make CSRF possible. So, even when you close the tab with mybank.com, the cookie ist still there, so CSRF is still possible.
– Alex
1 hour ago
@Alex Thanks! Is that edit in line with what you were thinking?
– Mike Ounsworth
1 hour ago
yes thats what I was thinking about
– Alex
1 hour ago
add a comment |
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 hours ago
Mike OunsworthMike Ounsworth
39.1k1593138
1
I think you nailed it, just want to clear one thing up because it might be confusing: CSRF does not directly depend on browser tabs. Your browser just need to have a cookie for www.mybank.com stored to make CSRF possible. So, even when you close the tab with mybank.com, the cookie ist still there, so CSRF is still possible.
– Alex
1 hour ago
@Alex Thanks! Is that edit in line with what you were thinking?
– Mike Ounsworth
1 hour ago
yes thats what I was thinking about
– Alex
1 hour ago
add a comment |
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 hours ago
Mike OunsworthMike Ounsworth
39.1k1593138
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 hours ago
Mike OunsworthMike Ounsworth
39.1k1593138
edited 1 hour ago
answered 2 hours ago
Mike OunsworthMike Ounsworth
39.1k1593138
answered 2 hours ago
Mike OunsworthMike Ounsworth
39.1k1593138
answered 2 hours ago
Mike OunsworthMike Ounsworth
39.1k1593138
39.1k1593138
1
I think you nailed it, just want to clear one thing up because it might be confusing: CSRF does not directly depend on browser tabs. Your browser just need to have a cookie for www.mybank.com stored to make CSRF possible. So, even when you close the tab with mybank.com, the cookie ist still there, so CSRF is still possible.
– Alex
1 hour ago
@Alex Thanks! Is that edit in line with what you were thinking?
– Mike Ounsworth
1 hour ago
yes thats what I was thinking about
– Alex
1 hour ago
add a comment |
1
I think you nailed it, just want to clear one thing up because it might be confusing: CSRF does not directly depend on browser tabs. Your browser just need to have a cookie for www.mybank.com stored to make CSRF possible. So, even when you close the tab with mybank.com, the cookie ist still there, so CSRF is still possible.
– Alex
1 hour ago
@Alex Thanks! Is that edit in line with what you were thinking?
– Mike Ounsworth
1 hour ago
yes thats what I was thinking about
– Alex
1 hour ago
1
1
I think you nailed it, just want to clear one thing up because it might be confusing: CSRF does not directly depend on browser tabs. Your browser just need to have a cookie for www.mybank.com stored to make CSRF possible. So, even when you close the tab with mybank.com, the cookie ist still there, so CSRF is still possible.
– Alex
1 hour ago
I think you nailed it, just want to clear one thing up because it might be confusing: CSRF does not directly depend on browser tabs. Your browser just need to have a cookie for www.mybank.com stored to make CSRF possible. So, even when you close the tab with mybank.com, the cookie ist still there, so CSRF is still possible.
– Alex
1 hour ago
@Alex Thanks! Is that edit in line with what you were thinking?
– Mike Ounsworth
1 hour ago
@Alex Thanks! Is that edit in line with what you were thinking?
– Mike Ounsworth
1 hour ago
yes thats what I was thinking about
– Alex
1 hour ago
yes thats what I was thinking about
– Alex
1 hour ago
add a comment |
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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
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
