Protection against CSRF added #22077

pboguslawski · 2022-12-09T08:00:02Z

Details sent to security@gitea.io in messages

Wed, 30 Nov 2022 12:47:33 +0100.
Fri, 2 Dec 2022 19:59:02 +0100

Author-Change-Id: IB#1129006

mscherer · 2022-12-21T14:13:59Z

routers/common/middleware.go

@@ -1,4 +1,4 @@
-// Copyright 2021 The Gitea Authors. All rights reserved.
+// Copyright 2022 The Gitea Authors. All rights reserved.


AFAIK, updating the copyright year is kinda useless nowadays, as using git is sufficient to establish who/when the work was done (which is why there is "the gitea authors" and not the detail). That's the opinion of the Linux Foundation ( https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-software-projects , the author is the Vice President of Compliance and Legal ). I also got the same answer from our legal department, even if I haven't been able to convince them to publish something outside our intranet.

mscherer · 2022-12-21T14:15:00Z

routers/common/middleware.go

+
+			// Allow requests not recognized as CSRF.
+			secFetchSite := strings.ToLower(req.Header.Get("Sec-Fetch-Site"))
+			if req.Method == "GET" || // GET must not be used for changing state (CSRF resistant).


Shouldn't it also cover HEAD ?

Added HEAD and OPTIONS also.

zeripath · 2022-12-22T15:35:28Z

I actually have a feeling that we should not be allowing the ReverseProxy Auth on the API - it's the only consistent way of making the API work

Since we changed the /api/v1/ routes to disallow session authentication we also removed their reliance on CSRF. However, we left the ReverseProxy authentication here - but this means that POSTs to the API are no longer protected by CSRF. Now, ReverseProxy authentication is a kind of session authentication, and is therefore inconsistent with the removal of session from the API. This PR proposes that we simply remove the ReverseProxy authentication from the API and therefore users of the API must explicitly use tokens or basic authentication. Replace go-gitea#22077 Signed-off-by: Andrew Thornton <art27@cantab.net>

zeripath · 2022-12-22T16:09:36Z

I don't fully understand why you have added another dependency library for the cors instead of making our current one work or replacing our current one.

According to https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#javascript-guidance-for-auto-inclusion-of-csrf-tokens-as-an-ajax-request-header GET, HEAD and OPTIONS should not be used for changing state.

pboguslawski · 2022-12-22T16:34:43Z

I actually have a feeling that we should not be allowing the ReverseProxy Auth on the API - it's the only consistent way of making the API work

What inconsistency do you see in using same auth method (header auth from reverse proxy) for all API calls? Any risks?

I don't fully understand why you have added another dependency library for the cors instead of making our current one work or replacing our current one.

https://github.com/go-chi/cors does not provide OriginAllowed method and it seems even maintainer is not sure why this fork is still for. Existing CSRF code was not analyzed and left untouched; if this PR is accepted - existing token based CSRF stuff should be checked and (if is still required as separate line of defense) may be switched to github.com/rs/cors or removed (if not required when browsers compatible with fetch metadata headers will be required for gitea).

zeripath · 2022-12-22T17:03:43Z

I actually have a feeling that we should not be allowing the ReverseProxy Auth on the API - it's the only consistent way of making the API work

What inconsistency you see in using one auth method for all API calls?

For every other authentication mechanism we now require that API calls are separately and explicitly authenticated - this makes ReverseProxy the odd one out.

I don't fully understand why you have added another dependency library for the cors instead of making our current one work or replacing our current one.

https://github.com/go-chi/cors does not provide OriginAllowed method and it seems even maintainer is not sure why this fork is still for. Existing CSRF code was not analyzed and left untouched; if this PR is accepted - existing token based CSRF stuff should be checked and (if is still required as separate line of defense) may be switched to github.com/rs/cors or removed (if not required when browsers compatible with fetch metadata headers will be required for gitea).

This PR means we now have TWO libraries adding CORS headers. We need to use one or the other not both. It's fine to say that we shouldn't be using the go-chi/cors fork but we then we need to not use it.

This PR doesn't appear to add CSRF token checking as far as I can see? I guess that also needs to be added?

pboguslawski · 2022-12-22T17:15:19Z

For every other authentication mechanism we now require that API calls are separately and explicitly authenticated - this makes ReverseProxy the odd one out.

If account A can make change X using "web API" why shouldn't be allowed to make same change X using "API"? Why to "mess" with separate API areas and separate sets of auths for both? Any real risks?

If separation is required - why not to introduce user permissions to access given API area (i.e. "[x] access to web", "[x] access to API) as alternative to application tokens (which should be optional)?

This PR means we now have TWO libraries adding CORS headers.

Code in this PR does not handle CORS requests/reponses it only uses CORS stuff to decide if requests are valid during CSRF validation. If this PR is accepted - existing CORS may be switched to github.com/rs/cors to avoid using two CORS libs (should not hurt as temporary solution).

zeripath · 2022-12-23T20:02:24Z

If account A can make change X using "web API" why shouldn't be allowed to make same change X using "API"? Why to "mess" with separate API areas and separate sets of auths for both? Any real risks?

I didn't complete agree with the decision to do this - but it was done. ReverseProxy currently stands as the odd one out.

The idea is that you have to authenticate explicitly for the API separately from the UI.

If separation is required - why not to introduce user permissions to access given API area (i.e. "[x] access to web", "[x] access to API) as alternative to application tokens (which should be optional)?

Or use tokens that we already have.

This PR means we now have TWO libraries adding CORS headers.

Code in this PR does not handle CORS requests/reponses it only uses CORS stuff to decide if requests are valid during CSRF validation. If this PR is accepted - existing CORS may be switched to github.com/rs/cors to avoid using two CORS libs (should not hurt as temporary solution).

That's not the way to do things, it won't get done and we'll end up with 2 slightly different CORS libraries. The go-chi/cors library should be replaced in this PR. I won't approve this PR without that although I'm not going to block it.

Since we changed the /api/v1/ routes to disallow session authentication we also removed their reliance on CSRF. However, we left the ReverseProxy authentication here - but this means that POSTs to the API are no longer protected by CSRF. Now, ReverseProxy authentication is a kind of session authentication, and is therefore inconsistent with the removal of session from the API. This PR proposes that we simply remove the ReverseProxy authentication from the API and therefore users of the API must explicitly use tokens or basic authentication. Replace #22077 Close #22221 Close #22077 Signed-off-by: Andrew Thornton <art27@cantab.net>

Since we changed the /api/v1/ routes to disallow session authentication we also removed their reliance on CSRF. However, we left the ReverseProxy authentication here - but this means that POSTs to the API are no longer protected by CSRF. Now, ReverseProxy authentication is a kind of session authentication, and is therefore inconsistent with the removal of session from the API. This PR proposes that we simply remove the ReverseProxy authentication from the API and therefore users of the API must explicitly use tokens or basic authentication. Replace go-gitea#22077 Close go-gitea#22221 Close go-gitea#22077 Signed-off-by: Andrew Thornton <art27@cantab.net>

backport from #22219 Since we changed the /api/v1/ routes to disallow session authentication we also removed their reliance on CSRF. However, we left the ReverseProxy authentication here - but this means that POSTs to the API are no longer protected by CSRF. Now, ReverseProxy authentication is a kind of session authentication, and is therefore inconsistent with the removal of session from the API. This PR proposes that we simply remove the ReverseProxy authentication from the API and therefore users of the API must explicitly use tokens or basic authentication. Replace #22077 Close #22221 Close #22077 Signed-off-by: Andrew Thornton <art27@cantab.net> Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: zeripath <art27@cantab.net>

backport #22219 Since we changed the /api/v1/ routes to disallow session authentication we also removed their reliance on CSRF. However, we left the ReverseProxy authentication here - but this means that POSTs to the API are no longer protected by CSRF. Now, ReverseProxy authentication is a kind of session authentication, and is therefore inconsistent with the removal of session from the API. This PR proposes that we simply remove the ReverseProxy authentication from the API and therefore users of the API must explicitly use tokens or basic authentication. Replace #22077 Close #22221 Close #22077 Signed-off-by: Andrew Thornton <art27@cantab.net> Signed-off-by: Andrew Thornton <art27@cantab.net> Co-authored-by: zeripath <art27@cantab.net>

pboguslawski added 2 commits December 2, 2022 17:43

Protection against CSRF added

3ad72fa

Author-Change-Id: IB#1129006

Merge main into main-IB#1129006

6cbff66

yardenshoham added the topic/security Something leaks user information or is otherwise vulnerable. Should be fixed! label Dec 11, 2022

yardenshoham added this to the 1.19.0 milestone Dec 11, 2022

mscherer reviewed Dec 21, 2022

View reviewed changes

GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Dec 21, 2022

mscherer reviewed Dec 21, 2022

View reviewed changes

This was referenced Dec 22, 2022

Remove ReverseProxy authentication from the API #22219

Merged

Add CSRF protection to ReverseProxy authentication on API #22221

Closed

pboguslawski added 2 commits December 22, 2022 17:18

Update cors.go

2b20046

Update middleware.go

c5f3abe

According to https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#javascript-guidance-for-auto-inclusion-of-csrf-tokens-as-an-ajax-request-header GET, HEAD and OPTIONS should not be used for changing state.

lunny closed this in #22219 Dec 27, 2022

lunny mentioned this pull request Dec 27, 2022

Remove ReverseProxy authentication from the API (#22219) #22251

Merged

lunny mentioned this pull request Dec 27, 2022

Remove ReverseProxy authentication from the API (#22219) #22252

Merged

go-gitea locked and limited conversation to collaborators May 3, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Protection against CSRF added #22077

Protection against CSRF added #22077

pboguslawski commented Dec 9, 2022

mscherer Dec 21, 2022

pboguslawski Dec 22, 2022

mscherer Dec 21, 2022

pboguslawski Dec 22, 2022

zeripath commented Dec 22, 2022

zeripath commented Dec 22, 2022

pboguslawski commented Dec 22, 2022 •

edited

Loading

zeripath commented Dec 22, 2022 •

edited

Loading

pboguslawski commented Dec 22, 2022 •

edited

Loading

zeripath commented Dec 23, 2022

		@@ -1,4 +1,4 @@
		// Copyright 2021 The Gitea Authors. All rights reserved.
		// Copyright 2022 The Gitea Authors. All rights reserved.

Protection against CSRF added #22077

Protection against CSRF added #22077

Conversation

pboguslawski commented Dec 9, 2022

mscherer Dec 21, 2022

Choose a reason for hiding this comment

pboguslawski Dec 22, 2022

Choose a reason for hiding this comment

mscherer Dec 21, 2022

Choose a reason for hiding this comment

pboguslawski Dec 22, 2022

Choose a reason for hiding this comment

zeripath commented Dec 22, 2022

zeripath commented Dec 22, 2022

pboguslawski commented Dec 22, 2022 • edited Loading

zeripath commented Dec 22, 2022 • edited Loading

pboguslawski commented Dec 22, 2022 • edited Loading

zeripath commented Dec 23, 2022

pboguslawski commented Dec 22, 2022 •

edited

Loading

zeripath commented Dec 22, 2022 •

edited

Loading

pboguslawski commented Dec 22, 2022 •

edited

Loading