[x]
):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.
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
The root cause:
https://github.com/go-gitea/gitea/blob/b34996a62937b23121d19912b37ed2b1023f1479/routers/routes/routes.go#L444-L445
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:
https://github.com/gogs/gogs/issues/5599
https://github.com/gogs/gogs/blob/f545faa06d553750b9f4018336e810530389f88c/cmd/web.go#L338-L340
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
@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.
curl -s https://try.gitea.io/ | grep csrf
Content-Disposition: form-data; name="file"; filename="test.txt"
Content-Type: image/png
<here are binary data from a png file>
--boundary--
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'
{"uuid":"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?
Tested as working in Gitea Version: 1.9.0+dev-61-g7ed65a98e.
Most helpful comment
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