attachments accessible without authorization #2203

New Issue

GiteaMirror · 2025-11-02T04:26:55-06:00

GiteaMirror commented

2025-11-02 04:26:55 -06:00

Originally created by @noerw on GitHub (Aug 15, 2018).

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.

Originally created by @noerw on GitHub (Aug 15, 2018).  - Gitea version (or commit ref): f24ba27, 1.4.3 - Git version: - Operating system: - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] 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.

GiteaMirror added the topic/security label 2025-11-02 04:26:55 -06:00

GiteaMirror closed this issue

2025-11-02 04:26:55 -06:00

GiteaMirror commented

2025-11-02 04:26:56 -06:00

@leepfrog-ger commented on GitHub (Aug 20, 2018):

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

@leepfrog-ger commented on GitHub (Aug 20, 2018): > 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

GiteaMirror commented

2025-11-02 04:26:56 -06:00

@cs8425 commented on GitHub (Mar 31, 2019):

The root cause:
b34996a629/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
f545faa06d/cmd/web.go (L338-L340)

@cs8425 commented on GitHub (Mar 31, 2019): 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

GiteaMirror commented

2025-11-02 04:26:56 -06:00

@adelowo commented on GitHub (Mar 31, 2019):

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 commented on GitHub (Mar 31, 2019): 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

GiteaMirror commented

2025-11-02 04:26:56 -06:00

@cs8425 commented on GitHub (Apr 1, 2019):

@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.

get CSRF token by curl -s https://try.gitea.io/ | grep csrf
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--

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'
got {"uuid":"93fdc72f-a2e2-4bbb-8930-07105c29513f"}
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?

@cs8425 commented on GitHub (Apr 1, 2019): @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: ![test](https://user-images.githubusercontent.com/1642768/55313580-b0d5a900-549a-11e9-8308-61167e52de20.png) 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?

GiteaMirror commented

2025-11-02 04:26:56 -06:00

@chotaire commented on GitHub (Apr 7, 2019):

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

@chotaire commented on GitHub (Apr 7, 2019): Tested as working in Gitea Version: 1.9.0+dev-61-g7ed65a98e.

GiteaMirror referenced this issue

2025-11-02 12:06:44 -06:00

[PR #2203] [MERGED] Fix Commits nil pointer dereference #16285

Sign in to join this conversation.