Is the core idea behind CSRF protection that the hacker doesn't know the token value?












29















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







share|improve this question


















  • 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
















29















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







share|improve this question


















  • 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














29












29








29


6






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







share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jan 17 at 14:50









MeanGreenMeanGreen

24625




24625








  • 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














  • 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








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










1 Answer
1






active

oldest

votes


















24














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






share|improve this answer





















  • 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













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
});


}
});














draft saved

draft discarded


















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









24














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






share|improve this answer





















  • 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


















24














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






share|improve this answer





















  • 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
















24












24








24







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






share|improve this answer















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







share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 17 at 16:07

























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
















  • 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




















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







-

Popular posts from this blog

mysqli_query(): Empty query in /home/lucindabrummitt/public_html/blog/wp-includes/wp-db.php on line 1924

Image
0 I just uploaded a new plugin to my wordpress site and I got this warning: mysqli_query(): Empty query in /home/lucindabrummitt/public_html/blog/wp-includes/wp-db.php on line 1924 Usually if I have a problem, I can find answers on google but this one seems pretty particular and I'm not finding any info on it except for this forum. I'm not terribly techie but if someone can tell me how to read this and how to change it I can follow directions pretty well. Thanks All! PS If I don't have the proper tags here could someone add the appropriate tags? php mysql wordpress share | improve this question asked Nov 16 '18 at 20:41 ...
Read more

How to change which sound is reproduced for terminal bell?

Image
3 Recently upgrade to 18.10 from 18.04, and using the terminal is becoming annoying: the new alert sound is a drip ( /usr/share/sounds/gnome/default/alerts/drip.ogg ), and the previous one is still located at ( /usr/share/sounds/ubuntu/stereo/bell.ogg ). My issue is that at the gnome-terminal, when autocompleting or pressing left BOTH sounds are reproduced, at the same time. I want to just have ubuntu/stereo/bell.ogg active, not both . At the moment I have been only able to reduce the volume of the alerts (but still both are played), or turn the alerts down (but I dislike both "solutions"). gnome-terminal 18.10 teminal-bell share | improve this question ...
Read more

Can I use Tabulator js library in my java Spring + Thymeleaf project?

Image
0 I want to add Tabulator js to my java project. I added tabulator.min.js, tabulator.min.css to resources folder. After that added to my html page these dependencies as recommending in readme.md. <link rel="stylesheet" th:href="@{/css/tabulator.min.css}"> <script type="text/javascript" th:src="@{/js/tabulator.min.js}"></script> Now my tables view all elements, that I have in the html page, but not correct. In the documentation of Tabulator is example how to create header and table, var table = new Tabulator("#example-table", { columns:[ {title:"Name", field:"name", sorter:"string", width:200, editor:true}, {title:"Age", field:"age", sorter:"...
Read more