[Security] CSRF Vulnerability on API

[ghost]

• Gitea version (or commit ref): every version with swagger api
• Git version: not relevant
• Operating system: not relevant
• 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

Screenshots

[lunny]

Because Gitea's UI are also using some APIs, so the APIs support many authorizations(session is one of them). But have you found any missing permissions checking? Could you send a security email to security@gitea.io?

[lunny]

I think you are right. Maybe we should use different routes for UI and APIs.

[techknowlogick]

The way the WordPress API works is that if cookie auth is used (vs token auth), then a nonce has to be sent as well, the nonce is injected into the html template for JS to use and pass to the API and act as a second factor. (I've seen this approach in other implementations, it is just that WP is most well known)

Even if we did different routes for UI/API the UI ajax routes would still be affected.

More and more functionality is being built that uses the API (issue date, etc..) via the UI, and so we should work towards resolving the issue above.

[techknowlogick]

Perhaps we could use the CSRF token as a second factor

[techknowlogick]

Anyone looking at this https://github.com/go-gitea/gitea/blob/master/routers/api/v1/api.go#L133 reqToken just validates that the user is signed in, not that they are using a valid token.

[beeonthego]

Is someone working on this issue now? if not, I will prepare a PR and check whether a token (or basic auth) has been used to authenticate. the check can be added to reqToken handler. There are a few minor changes, non breaking.