-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support setting cookie domain #6288
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an important security measure and shouldn't be set to false. By setting this to false an attacker could gain access to the cookie.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am following this article: http://www.redotheweb.com/2015/11/09/api-security.html
You are right in that
session cookie
must be HTTPOnly to protect against XSS attack. But it is ok to make CSRF cookie readable by JS and usually passed as header or request body in a CORS ajax call.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also agree with @techknowlogick that it should be
true
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lunny, please take a look at https://medium.com/@iaincollins/csrf-tokens-via-ajax-a885c7305d4a . When we are using Vue (ajax), we need to read the csrf from JS to pass it to api calls. There is no benefit to making csrf cookie HTTPOnly. Frameworks like Django / Laravel make csrf token not HTTPOnly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that the content from the meta tag (
<meta name="_csrf" content=
) is what is needed for JS to pass it to API calls using theX-Csrf-Token
header.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@techknowlogick , it seems that both techniques are used. See here for Laravel https://laravel.com/docs/5.8/csrf .
In terms of security, the goal of HTTPOnly cookie is to ensure that JS can't read that. But if that same value is set on meta tag, that JS can easily read it. So, by making this cookie HTTPonly, we are not achieving anything more security wise.
In our case, _meta tag does not work, because we want to access the csrf token from a Vue / SPA app that is running on a subdomain. That Vue app is purely SPA and does not connect with the same gitea backend. So, we can't set the meta tag. But the cookie technique works well for us. The csrf cookie is set on the
.domain.com
, so my SPA running onsubdom.domain.com
can read and pass on that to ajax request as header.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The API should be used in this case, however I can see that you do have a use case for the way you are proposing, and while I feel it would be less secure perhaps we could reach a compromise. Just like your other PR with CORS, perhaps similar to that we make this customizable where HTTPOnly setting (default to true) could be configured along side with the domain for the cookie.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can make it configurable. That works for us. Should I call it
setting.CSRFCookieHttpOnly
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added a setting under
security.CSRF_COOKIE_HTTP_ONLY
. PTAL.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks :)