attachments accessible without authorization

[noerw]

• Gitea version (or commit ref): f24ba27, 1.4.3
• Git version:
• Operating system:
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL): https://try.gitea.io/attachments/f3763540-6bf8-47c2-b2ce-0fa9c48f1e82
  • No
  • Not relevant
• Log gist:

Description

Attachments of a release on a private repository should not be accessible without authorization!

For example check the following private repo: https://try.gitea.io/norwin/test/releases
The release has an attachment, which can be accessed without authentication via
https://try.gitea.io/attachments/f3763540-6bf8-47c2-b2ce-0fa9c48f1e82

You could argue that the UUID provides security, but I would definitely feel safer if the attachments were protected by the same ACLs that govern the code-tarball associated with each release in case the direct link leaks somewhere.

[leepfrog-ger]

You could argue that the UUID provides security

There are many cases where links might get leaked to another party (e.g. browser addon, some tool reading the download history, using untrusted chat services, proxy server...).
So I agree that this should be treated as security issue

[cs8425]

The root cause:

gitea/routers/routes/routes.go

Lines 444 to 445 in b34996a

	m.Post("/attachments", repo.UploadAttachment)
	}, ignSignIn)

We should add some verifying for m.Post("/attachments", repo.UploadAttachment).
Where are we using POST to /attachments?
Upload attachments for repo/issue/comment only?
At least needs login for sure.

this issue existed at gogs too:
gogs/gogs#5599
https://github.com/gogs/gogs/blob/f545faa06d553750b9f4018336e810530389f88c/cmd/web.go#L338-L340

[adelowo]

To be fair, even images uploaded in a private repo on GitHub are accessible without authorization.

I think another issue is tracking this same bug as I must have made the above comment somewhere before

[cs8425]

@adelowo
I mean that anyone can upload without authorization.
I use the same method which gogs issue reported, and with a little modify, it still works.

1. get CSRF token by curl -s https://try.gitea.io/ | grep csrf
2. make a multipart/form-data

--boundary
Content-Disposition: form-data; name="file"; filename="test.txt"
Content-Type: image/png

<here are binary data from a png file>
--boundary--

3. upload data by: curl -kis -X 'POST' -H "X-Csrf-Token: $CSRF" -H 'Content-Type: multipart/form-data; boundary=boundary' -b "lang=en-US; _csrf=$CSRF" --data-binary @req.txt 'https://try.gitea.io/attachments'
4. got {"uuid":"93fdc72f-a2e2-4bbb-8930-07105c29513f"}
5. check the file: https://try.gitea.io/attachments/93fdc72f-a2e2-4bbb-8930-07105c29513f

And I found that if remove the file from here:

There are no any http request to notify server to delete it.
Both may cause DoS attack for disk space.
First one is easy to fix, just set request login before upload.
But the second need more work, we need to check who can delete the uploaded file.
Or I should create a new issue for this?

[chotaire]

Tested as working in Gitea Version: 1.9.0+dev-61-g7ed65a98e.