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 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.
The text was updated successfully, but these errors were encountered:
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
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
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?
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 accepttoken_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 withget*
--> 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:
From Matomo 6
The text was updated successfully, but these errors were encountered: