.htaccess installed and respected which blocks any access to
matomo/config, which can be verified by manually trying to access the directory or any contained file and running a curl locally and remotely, the Matomo system check should not throw a related "critical issues".
https://domain.com/matomo/config/config.ini.php We found that the above URLs are accessible via the browser, but they should NOT be. Allowing them to be accessed can pose a potential security risk since the contents can provide information about your server and potentially your users. Please restrict access to them. We also found that Matomo's config directory is publicly accessible. While attackers can't read the config now, if your webserver stops executing PHP files for some reason, your MySQL credentials and other information will be available to anyone. Please check your webserver config and deny access to this directory.
TBD, I'll have a look into the code.
API, Actions, Annotations, BotTracker 2.01, BulkTracking, Contents, CoreAdminHome, CoreConsole, CoreHome, CorePluginsAdmin, CoreUpdater, CoreVisualizations, CustomJsTracker, DBStats, DarkTheme 1.1.6, Dashboard, DevicePlugins, DevicesDetection, Diagnostics, Goals, Heartbeat, ImageGraph, Insights, Installation, Intl, LanguagesManager, Live, LogViewer 4.0.1, Login, Marketplace, Monolog, Morpheus, Overlay, PagePerformance, PrivacyManager, Proxy, Referrers, Resolution, SEO, SegmentEditor, SitesManager, Transitions, UserLanguage, UsersManager, VisitFrequency, VisitTime, VisitorInterest, VisitsSummary, WebsiteMeasurable
What exactly is the output of
curl -v https://domain.com/matomo/config/config.ini.php.
Does it respond with a 403 or return just a
HTTP/2 403 to be precise, in both bases, when running from the server itself as well as when running from a remote machine (where it's behind Cloudflare). But a 403 + 404 handler page is shown, no empty response body.
That will be the issue: $isAccessible = strpos($data, ';') !== false; is used to check access to the config file, hence not the response code. Since the 40x handler page can of course contain a
;, this will return a wrong result in very most cases. Is there a reason to not check the response code as well for the config file?
Many thanks, the fix works here as well :+1:.
Thanks @MichaIng for finding this issue in the RC before the release and letting us know :100:
My pleasure, thanks for developing a great self-hosted analytics platform 🙂,