Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to only allow tokens to be POSTed #235 #19234

Closed
tsteur opened this issue May 18, 2022 · 3 comments · Fixed by #20351
Closed

Add ability to only allow tokens to be POSTed #235 #19234

tsteur opened this issue May 18, 2022 · 3 comments · Fixed by #20351
Assignees
Labels
duplicate For issues that already existed in our issue tracker and were reported previously.
Milestone

Comments

@tsteur
Copy link
Member

tsteur commented May 18, 2022

Currently, users can pass the token_auth for the API using a GET or POST token. For better security, we should have an option to not accept token_auth via URL parameters.

Exception: This would only apply to API requests that aren't coming from the UI. That means if there is an API request that has the force_api_session parameter AND it is the session token_auth (not a regular token_auth), then it can be still in the URL if the API actions starts with get* --> This might be already implemented, to be checked. This way for example the export in the UI still works nicely. Also for these requests it's less of a security issue if the token_auth appears in logs as they aren't usable without the session ID.

How this feature could work:

  • When creating a new token_auth there could be an option to control the usage of the token in URL parameters. By default, it would only allow the usage in POST requests but not as a URL parameter. Someone could enable this option to allow the usage in a URL parameter. Ideally the description would say that we recommend only allowing POST for best security.
    • To be defined what this would mean for cases where people use the token for embedding a widget or an image (eg sparkline). The description of this option would maybe also need to explain that URL parameters may need to be allowed if someone wants to use the token to embed widgets.
  • When someone tries to create a token that doesn't allow usage in URL parameter and tries to use it in a url parameter, we should have a proper error message.
  • All existing tokens would still allow the usage in URL parameters
  • We would need to adjust various docs like https://matomo.org/faq/general/faq_114/ , https://developer.matomo.org/api-reference/tracking-api and https://developer.matomo.org/api-reference/reporting-api
  • For companies that want best security there should be also a config setting to force usage of token via POST for all tokens.
  • We could potentially also allow the token in a header when HTTPS is used similar to https://swagger.io/docs/specification/authentication/bearer-authentication/ , although not sure if there are any pros or cons?
  • We also need to look for popular community integrations that may use the token_auth and create an issue on their Github for them to check that they POST the token and not use it in a URL parameter. We could mention that from Matomo 5 newly created token_auths by default will only support POST.
  • We might also want to double check the PHP tracker and the log importer that we are posting the token
  • [I would need to double check and make sure that Matomo Mobile POSTs token auths if that's not the case yet. Problem: ImageGraph API is being used to request images and therefore have the token_auth in the URL very likely].

From Matomo 6

  • Maybe then we could completely disallow usage of GET for newly created tokens unless specifically allowed using a config option. Or we may need to keep the option for the use case when using the token_auth in widgets. In that case we would only allow the usage in URL parameters for widgets but not for a regular API request when URL parameters are allowed.
@tsteur tsteur added the c: Security For issues that make Matomo more secure. Please report issues through HackerOne and not in Github. label May 18, 2022
@tsteur tsteur added this to the 5.0.0 milestone May 18, 2022
@tsteur tsteur closed this as completed May 18, 2022
@tsteur tsteur added duplicate For issues that already existed in our issue tracker and were reported previously. and removed c: Security For issues that make Matomo more secure. Please report issues through HackerOne and not in Github. labels May 18, 2022
@mattab mattab reopened this Nov 9, 2022
@mattab mattab added the 5.0.0 label Jan 4, 2023
@bx80 bx80 self-assigned this Feb 9, 2023
@sgiehl sgiehl closed this as completed Mar 17, 2023
@uschindler
Copy link

IMHO, it should be additionally possible to sent the tokens as Authorization: bearer TOKEN header. Sending it in URL or POST is not according to REST standards. This annoyed me already when using the API. Should I open another issue or is this already fixed in Matomo 5?

@sgiehl
Copy link
Member

sgiehl commented May 6, 2023

This isn't included in Matomo 5 yet. So having a new issue for it might be good.

@uschindler
Copy link

I opened #20677.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate For issues that already existed in our issue tracker and were reported previously.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants