Support setting cookie domain

[tamalsaha]

We are building a website where the session cookie is set to example.com domain. Later a SPA hosted on a subdomain.example.com will make api calls to example.com/api/xyz. In this scenario we want to set the csrf cookie domain to .example.com so that SPA can pass it along the ajax api calls.

Thanks.

[codecov-io]

Codecov Report

Merging #6288 into master will increase coverage by <.01%.
The diff coverage is 76%.

@@            Coverage Diff             @@
##           master    #6288      +/-   ##
==========================================
+ Coverage   41.19%   41.19%   +<.01%     
==========================================
  Files         469      469              
  Lines       63544    63549       +5     
==========================================
+ Hits        26176    26179       +3     
- Misses      33946    33948       +2     
  Partials     3422     3422

Impacted Files	Coverage Δ
modules/setting/setting.go	49.22% <100%> (+0.17%)	⬆️
routers/user/setting/profile.go	40.26% <100%> (ø)	⬆️
routers/routes/routes.go	82.4% <100%> (+0.04%)	⬆️
modules/setting/session.go	86.36% <100%> (+0.64%)	⬆️
routers/user/auth.go	12.04% <50%> (ø)	⬆️
modules/log/event.go	64.61% <0%> (-1.03%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update efaee46...6ca12ef. Read the comment docs.

[techknowlogick]

The changes are concerning from a security perspective. Perhaps now that we have OAuth2 you could use that to generate a token that could be used for the API in your SPA instead.

[techknowlogick]

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.

[tamalsaha]

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.

[lunny]

I also agree with @techknowlogick that it should be true.

[tamalsaha]

@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.

It’s important to note you should use HTTP Only cookies for your session tokens (which is best practice and provides protection against XSS attacks). However, CSRF tokens do not need to be stored in cookies — but they can be and unlike session tokens they do not need to be HTTP Only cookies.

[techknowlogick]

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 the X-Csrf-Token header.

[tamalsaha]

@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 on subdom.domain.com can read and pass on that to ajax request as header.

[techknowlogick]

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.

[tamalsaha]

I can make it configurable. That works for us. Should I call it setting.CSRFCookieHttpOnly ?

[tamalsaha]

I have added a setting under security.CSRF_COOKIE_HTTP_ONLY. PTAL.

[techknowlogick]

Thanks :)

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 months. Thank you for your contributions.

[tamalsaha]

@techknowlogick / @lunny, I wonder if you can take a look at this pr.

[lunny]

@tamalsaha will review this on weekend.

[tamalsaha]

@lunny , ping 🙏 ?

[lunny]

the blank line should be kept.

[lunny]

I also agree with @techknowlogick that it should be true.

[tamalsaha]

@techknowlogick / @lunny , if everything looks good, please give it a lgtm ? :)

[techknowlogick]

Make LGTM work