Thanks for the report @DHammer-PT . I would encourage you also in future to consider reporting security issues via Hackerone - https://hackerone.com/matomo

Hackerone wants details on how to reproduce the exploit. Unfortunately I cannot provide that information. I would call this a theoretical vulnerability.

@tsteur are you able to take a look here and comment?

issue 1

File number one: js/piwik.js Line: 7236
iframe.contentWindow.postMessage(jsonMessage, '*');

This one could be an easy fix as we already check for originHost meaning instead of * we should be able to always use the originHost instead of * (but would also need to add protocol maybe).

The message another frame would receive in worst case is whether a user is currently opted in or out according to the first party cookie in JS tracker. In the past, we didn't really consider this much of an issue but it be an easy fix I believe.

issue 2

File number two: plugins/CoreAdminHome/javascripts/optOut.js Lines: 200
Line 200: parent.postMessage(JSON.stringify(message), '*');

By posting this message, a tracker would post the message from js/piwik.js Line: 7236 back. The tracker listening to this message already does check the host and only performs this action if it was received from a specific domain. Meaning other frames won't be able to trigger this action and other frames cannot opt you out or opt you in without your knowing.

Meaning what the * does is that other frames would know the opt in status when the user is changing the opt in status. It won't impact most of the visits/users etc as usually people on privacy policy don't opt out of Matomo or make changes there.

issue 3

File number two: plugins/CoreAdminHome/javascripts/optOut.js Lines: 200

This one will ask the parent window to send us initial state of the first party optout cookie so that we can display the opt out status correctly in the form. The tracker listening to this message already does check the host and only performs this action if it was received from a specific domain. Meaning other frames won't be able to trigger this action and the tracker won't reveal the first party cookie status when this is triggered from a different frame. However, this message will reveal the 3rd party cookie opt out status.

This third party cookie status you could maybe always figure out though if you wanted by simply embedding the Matomo opt out from anyone on your own site and then tricking someone to visit your site unless the * could be restricted to a specific config setting as mentioned in the issue description (opt out may stop working if this is set as it would require the configuration of all site url domains for every site so we can allow only specific site urls). The third party opt in status won't be much used anymore in the future so it's maybe less of an issue going forward.

Issue 2 and 3 be bit harder to fix. It be technically maybe easy to fix in the sense that we could have a boolean config to enable only specific URLs that this would be posted to. But then users will need to always configure all urls in Matomo sites manager and if one site url is forgotten to be configured for a site, then the opt out may not fully work there.

From my understanding, generally, by using * it won't allow you to trigger any action but by using the * it could tell another frame if the current user is opted in or opted out. This is happening as soon as the opt out iframe is loaded and when a user does change the opt out status.

@justinvelluppillai My recommendation here would be to fix issue 1 which should be fairly easy to do and ensures compliance for future.

Issue 2 and 3 I wouldn't fix at this point because we are deprecating the opt out iFrame in favour of #17452 . The iframe opt out won't even work anymore in the future as third party cookie support is being removed by browsers.

Technically, issue 1 is also not an issue if the iframe opt out isn't used as the message can only be triggered from the opt out script. It's still good though to have such best practice in place so this topic won't come up again and won't be detected by future security scans by other companies.

So I would fix issue 1 here.

@DHammer-PT in this current release we're changing the opt out from iframes towards a JS solution meaning issue 2 and 3 will be fixed indirectly in the sense that you won't need to use the iframe opt out solution anymore (which won't be future proof anymore). And there's additionally already the possibility to build a custom opt out form instead of the iframe solution.

If we disable the opt-out feature, would that make all three items a non issue for us? Or would #1 still be exploitable even with the feature disabled?

re #1 There could be an edge cases where it may still be possible that it does send the message if someone was to create a "tracker" instance with a Matomo URL tracking endpoint that is the same as the URL from the iframe. Like if there was an XSS vulnerability on your site, they could create a Matomo JS tracker instance and add an iframe that then triggers that message. In that case they could find out if someone opted out of tracking. If there was an XSS vulnerability on your site they'd likely to worse things but nonetheless this could be improved in the JS tracker and it should be an easy fix.

The issues were found when performing a code scan using SonarQube. The application found 3 security vulnerabilities. I am including them in a single submission since it is the same issue found in 3 places in two different files. Matamo version 4.10.1

File number one: js/pwiki.js Line: 7236

iframe.contentWindow.postMessage(jsonMessage, '*');

SonarQube reason: Origins should be verified during cross-origin communications

Our recommendation: create a URL variable that defaults to '*' but allow the value to be defined/overridden in a configuration setting.

File number two: plugins/CoreAdminHome/javascripts/optOut.js Lines: 105 and 200

Line 105: parent.postMessage(JSON.stringify(optOutStatus), "*");

Line 200: parent.postMessage(JSON.stringify(message), '*');

SonarQube reason: Origins should be verified during cross-origin communications

Our recommendation: create a URL variable that defaults to '*' but allow the value to be defined/overridden in a configuration setting.

If you need additional information, please let me know.

Leave a comment