@Findus23 opened this Issue on March 12th 2019 Member

I just noticed that the Web Cron Docs recommends accessing this URL (I just updated it to include https)
https://matomo.your-server.example/path/to/piwik/misc/cron/archive.php?token_auth=XYZ

Sending the admin token via GET isn't ideal, but it seems to be hardcoded:

https://github.com/matomo-org/matomo/blob/7edf461477aa2f732c3e1fda506d7a476d93b62d/misc/cron/archive.php#L60

Would it be possible to update the script to support POST (and mention it in the docs) or maybe even recommend people to directly call CoreAdminHome.runCronArchiving?

@simivar commented on March 29th 2019 Contributor

I see that archive.php script is deprecated while running from CLI and user is redirected to core:archive. What do you think about adding some DEPRECATED message in HTTP-mode while we are at it?

@mattab commented on July 26th 2021 Member

Added little mention in https://matomo.org/docs/setup-auto-archiving/

For security, if possible we recommend you POST the token_auth parameter to the URL https://matomo.your-server.example/path/to/matomo/misc/cron/archive.php (instead of sending the token_auth as a GET parameter)

@valerio-bozzolan commented on August 2nd 2021

Added little mention in https://matomo.org/docs/setup-auto-archiving/

For security, if possible we recommend you POST the token_auth parameter to the URL https://matomo.your-server.example/path/to/matomo/misc/cron/archive.php (instead of sending the token_auth as a GET parameter)

Note that POST has nothing to do with security. The reference should be updated to fix this misleading concept. The POST is just the right way to update things, like PUT. It does not add any underlying security measure, unless the user is so chicken that they share the GET URL with secrets in query string with someone at random.

Further notes:

https://developer.mozilla.org/en-US/docs/Glossary/Idempotent

@justinvelluppillai commented on August 2nd 2021 Contributor

@valerio-bozzolan it does at least have the security impact of not leaving token_auth in server logs I guess.

@valerio-bozzolan commented on August 9th 2021

On a normal Linux server, logs can be read only from root and from the webserver user by default. With or without the logs, both users can already read the token_auth because they can access the database or read the application config ecc., so having this information in a log does not have any security impact, unless one has an uncommon log management sharing them with untrusted users for uncommon reasons (but this workflow have security impacts, not GET). For this uncommon kind of users, yep, we can suggest to use POST but this is strange to be documented. That's why it's misleading to say that GET affects security.

This Issue was closed on June 25th 2021
Powered by GitHub Issue Mirror