API privacy / security - organization endpoints can be accessed without an access token

[OndrejSpanel]

• Gitea version (or commit ref): 1.6.2
• Git version: 1.9.1
• Operating system: Debian 7
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

Several API endpoints can be accessed without any authorization at all. I have found following GET requests which responded to me this way:

/orgs/{org}/repos
/orgs/{org}/members
/orgs/{org}

Some other endpoints I have tested require authorization (e.g. /orgs/{org}/hooks). I think the only gitea API endpoint which should be accessible without any authorization is version - any listing of repositories, users or organization should require it.

Screenshots

[markediez]

Hmm, I don't think this is an issue. GitHub allows unauthorized access in their APIs as well. I tried querying my org and it did not show my private repos given your steps.

[markediez]

/members endpoint only shows visible users
/repos endpoint only shows public repos
I don't see an option to set an org private.

[lafriks]

It should probably follow setting if public access is allowed or not and based on that require token or allow without it. Needs rechecking if this is really is issue or not

[OndrejSpanel]

I see my repro on gitea test server is not representative, given the server is public. My gitea server is set to allow access only to registered users (REQUIRE_SIGNIN_VIEW = true). It would be nice if API followed this setting as well.

[stale]

This issue 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 weeks. Thank you for your contributions.

[lunny]

According #6731, @OndrejSpanel there is no problem here.

[OndrejSpanel]

What I do not understand after reading that issue: Do you mean the behaviour I describe is as designed (or at least acceptable), or that the issue was fixed meanwhile?

[lunny]

@OndrejSpanel That means it's as designed. My tests haven't found a privacy / security problem on that. Those APIs will return public content when you have no access token.

[OndrejSpanel]

My issue about privacy is that I think no content should be considered "public" (accessible without an access token) when you require login even to access the Gitea main pages (i.e. when you use the option REQUIRE_SIGNIN_VIEW = true).

[mrsdizzie]

This is how it currently works, and what @lunny test show in #6731

If REQUIRE_SIGNIN_VIEW = true The API calls for the examples above all return

403
{
    "message": "Only signed in user is allowed to call APIs."
}

As they all should, based on:

gitea/modules/context/auth.go

Lines 75 to 83 in 19ec260

	if options.SignInRequired {
	if !ctx.IsSigned {
	// Restrict API calls with error message.
	if auth.IsAPIPath(ctx.Req.URL.Path) {
	ctx.JSON(403, map[string]string{
	"message": "Only signed in user is allowed to call APIs.",
	})
	return
	}

I don't see an example of this not working (the screenshot in the original issue is from public gitea that doesn't not have REQUIRE_SIGNIN_VIEW = true

Is there a specific example that can be seen of this not working?

[jtl999]

I was concerned about issues like this but before migrating to Gitea (from GitLab) but I tested with my local install (running 1.8 with REQUIRE_SIGNIN_VIEW set) and cannot reproduce.

Assuming there are no issues in auth.IsAPIPath function I don't see any issues here.

jtl@jtl-macbookpro-linux:~$ curl -X GET "http://10.2.2.32:3000/api/v1/users/search?q=jtl" -H  "accept: application/json" ; echo 
{"message":"Only signed in user is allowed to call APIs."}

[lunny]

Let's close this and please feel free to reopen it.

[OndrejSpanel]

I confirm the issue does not exist. My previous testing methodology was bad, as I was testing it in a browser session which has already performed the authentication. Testing in a fresh browser returns error as expected.

[jtl999]

No harm no foul. Better to be careful about these sorts of things.