Remove ReverseProxy authentication from the API

[zeripath]

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

[zeripath]

I've also reopened #22077 but with a few fixes and in such a way that we can update and merge it.

[jolheiser]

I agree with limiting to token auth (and basic...for now)

[pboguslawski]

What about protecting installations, where there is proxy between public and gitea that translates auth from say cookies/client certs/basic auths/... to auth method gitea understands (like token or basic auth after this PR is merged)? Seems that CSRF will still be possible and API auth methods removal is not a proper solution.

[delvh]

My (slightly uneducated) opinion on this topic:

What about protecting installations, where there is proxy between public and gitea that translates auth from say cookies/client certs/basic auths/... to auth method gitea understands (like token or basic auth after this PR is merged)?

I don't quite understand what you mean.
A malignant reverse proxy between the user and the gitea server that stores valid user credentials?
I doubt there is a way we can prevent that proxy from impersonating a user…
I mean, such a server can simply log in as the user, and make the call as the user themselves.
In this case, there is no point in securing anything because if this scenario happens, your entire credentials are compromised and your entire security is "on fire".

Additionally, we are talking about the API at the moment.
I first want to see the users that call the API from browsers, which is as far as I'm aware the main source of CSRF attacks.
If we removed this authentication from the web UI, this would be a completely different case.

[lunny]

Please send back port

[pboguslawski]

I don't quite understand what you mean.

Reverse proxy may have more intelligent auth methods that gitea currently has and may authenticate user using it. After authentication it must pass user login somehow to gitea using protocol gitea understands (only login is important to pass between proxy and gitea). One can think of many different solutions here, i.e. header with login only (best for this scenario IHMO), basic auth (login with dummy pass), token maybe, etc.

your entire credentials are compromised and your entire security is "on fire".

Auth and user credentials management is proxys job in this scenario and credentials are NOT compromised (gitea does not use passwords/tokens and blindly trust login passed from proxy). Proxy must pass login to gitea in secure manner (i.e. disallowing user A to act as user B) = path bettween proxy and gitea must be secured and trusted (i.e. not possible to sniff/change traffic).

Removing header auth from API part of gitea effectively makes upstream version of gitea poor solution for environments, where proxy auth and API must be used. Sad to see such regress.

[wxiaoguang]

Quote my comment from:

• Allow Token API calls be authorized using the reverse-proxy header #15119 (comment)

It's not ideal to use ReverseProxy for APIs. Security related mechanisms need complete designs.

I'd like to remind that this change may cause unexpected behaviors.

If I understand correctly, the reqBasicAuth was used to protect some privileged APIs like creating or deleting user's tokens. It was designed to require the API client (ex: GitNex) to force users to provide their password and OTP code for some privileged operations.

Normally, a GitNex client uses the access token to call APIs for daily usage. When it's going to do some privileged operations, the users should use user's password and OTP to verify that such operation is authorized to be done by the user themselves (double-verification).

After this change, the double-verification doesn't take affect for ReverseProxy. I am not sure whether it's expected, just share my opinions for reference.

[pboguslawski]

It's not ideal to use ReverseProxy for APIs.

Why?

Normally, a GitNex client uses the access token to call APIs for daily usage.

Using GitNex is not obligatory, especially if it lacks more advanced auth methods that reverse proxy may implement.

[wxiaoguang]

It's not ideal to use ReverseProxy for APIs.

Why?

It breaks the protection of the privileged APIs. By design (if I understand correctly), a user with 2FA must pass their 2FA to access the protected APIs, but the ReverseProxy auth knows nothing about it and can not provide such protection. Maybe it's not very serious in some cases, but since the mechanism exists, it should be a complete solution, or at least all edge cases should be documented first.

[pboguslawski]

It breaks the protection of the privileged APIs. By design (if I understand correctly), a user with 2FA must pass their 2FA to access the protected APIs, but the ReverseProxy auth knows nothing about it and can not provide such protection.

Giteas 2FA and Giteas "privileged APIs" should be optional. ReverseProxy may be used without 2FA at gitea side. Some ReverseProxys may handle 2FA and extra "privileges" itself (i.e. based on URL path or request payload).

[wxiaoguang]

It breaks the protection of the privileged APIs. By design (if I understand correctly), a user with 2FA must pass their 2FA to access the protected APIs, but the ReverseProxy auth knows nothing about it and can not provide such protection.

Giteas 2FA and Giteas "privileged APIs" should be optional. ReverseProxy may be used without 2FA at gitea side. Some ReverseProxys may handle 2FA and extra "privileges" itself (i.e. based on URL path or request payload).

I could agree if there are really some suitable ReverseProxys if they work properly. If a ReverseProxy could handle the extra "privileges", could it just use (let users provide) API access tokens when users access the APIs? It could be a more secure solution.

For me, personally I haven't understood why a user must call APIs without access token.

ps: I don't have strong preference since I am not using the ReverseProxy for Gitea either. Actually, I voted for allowing Gitea's web session to call API with CSRF protection before, and then it might be consistent to allow ReverseProxy auth to be used in API (the privileged part should also be re-designed). However at the moment, the API auth is designed to be different from web sessions, so I vote for keeping consistency (3rd auth for web, while access tokens for API). Just my opinion.

[pboguslawski]

For me, personally I haven't understood why a user must call APIs without access token

There are many other auth and permission assignment solutions, not just 2FA and token stuff. You can for example use simple machine account (separate username in gitea) and authenticate it to reverse proxy with strong auth method. If API need "privileged" areas - should probably be protected with separate permission set in user config not hardcoded with forcing one or other auth method. Authentication and authorization areas should be configured separately probably. Removing existing API auth method (reverse proxy) to keep hardcoded permission stuff working does not sound good (separate permission configured for user sounds better IHMO).

[vszakats]

It took a fair bit of research to reach to this PR. I expected such change listed under BREAKING. There is no mention about it in the reverse proxy docs, or the config example, which lists ENABLE_REVERSE_PROXY_AUTHENTICATION as before.

Before this patch, the situation was clear cut, the reverse proxy doing all the auth work and passing around a username to Gitea, for both UI and API. After this, the API side is unconditionally gone. Not only the API side, but direct Git access, too, apparently. (Both falling back to Basic Auth instead.)

What is a suggested replacement solution/configuration for such scenario?

[ Tried Access Tokens, but could not make it work in this context. ]

[jolheiser]

Ah, it looks like this PR is labeled breaking, but the backport wasn't, so it didn't end up in the breaking changes for the blog.
I will look at adding it to the blog, thanks for the reminder!

As for auth with git, you should be able to use basic auth with a token as the password if I'm remembering correctly.

[vszakats]

@jolheiser I wonder how to go through the reverse proxy's auth first, then go through a second, basic auth in Gitea itself? All this with a standard Git command. Is this feasible, or practical?

Thanks for the blog update. I looked at the release notes here, maybe something to consider updating too.