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

Jump to bottom

Displaying widgets in iframes logs bruteforce attacks #16867

Closed
olinox14 opened this issue Dec 2, 2020 · 7 comments · Fixed by #16903
Closed

Displaying widgets in iframes logs bruteforce attacks #16867

olinox14 opened this issue Dec 2, 2020 · 7 comments · Fixed by #16903
Assignees
@sgiehl
Labels
Regression Indicates a feature used to work in a certain way but it no longer does even though it should.
Milestone
4.0.x

Comments

@olinox14
Copy link

olinox14 commented Dec 2, 2020 •
edited

I use iframes to render some of the widgets in a website located on another server but on the same local network. Matomo's host and this website's are also subdomains of the same domain.

I added the iframes like suggested on the index.php?module=Widgetize&action=index page, with some little adjustments and using the token of a user who has the right to view the website:

<!-- Real time visits-->
<div class="widgetIframe" id="realTimeVisits"><iframe width="450" height="320" src="https://stats.mydomain.com/index.php?module=Widgetize&action=iframe&disableLink=1&widget=1&moduleToWidgetize=Live&actionToWidgetize=widget&idSite={matomoSiteId}&period=month&date=today&token_auth={matomoToken}" scrolling="yes" frameborder="0" marginheight="0" marginwidth="0"></iframe></div>

<!-- Last visits graph-->
<div class="widgetIframe" id="lastVisitsGraph"><iframe width="450" height="260" src="https://stats.mydomain.com/index.php?module=Widgetize&action=iframe&disableLink=1&widget=1&moduleToWidgetize=VisitsSummary&actionToWidgetize=getEvolutionGraph&idSite={matomoSiteId}&period=day&date=today&token_auth={matomoToken}" scrolling="yes" frameborder="0" marginheight="0" marginwidth="0"></iframe></div>

The widgets do appear as expected, however everytime the second iframe is rendered (getEvolutionGraph), a new entry is added to the matomo_brute_force_log table.

I also had this very same problem with the widget moduleToWidgetize=VisitsSummary&actionToWidgetize=get, but only when the parameters forceView=1&viewDataTable=VisitorLog where added to the url; if those parameters are removed, the problem disappear. Of course, removing these parameters do not resolve the getEvolutionGraph case...

Because of this problem, the user ip will be blocked for no reason if he visit the stats page more than the X times allowed by the brute force settings, making these widgets impossible to use in production.
@tsteur
Copy link
Member

tsteur commented Dec 2, 2020

Hi @olinox14 which version of Matomo are you using?

I just tried tried to reproduce this with Matomo 4 and it works there for me and doesn't log any brute force records. I think I remember there was some similar issue in some specific Matomo version but this might be fixed in a recent update.

@tsteur tsteur added the Can't reproduce (yet) For issues that are reported by several people, but can't be reproduced reliably and need more data label Dec 2, 2020
@olinox14
Copy link
Author

olinox14 commented Dec 3, 2020 •
edited

Hi @tsteur
I'm using matomo 4.0 too, I attach a copy of the system check: matomo_syscheck.txt

I'm implementing a stats page in a Typo3 CMS backend module.

I tried to give the right to view the site to anonymous user, then by using an actual user and adding its token_auth to the iframes urls, same issue.

@sgiehl sgiehl added Regression Indicates a feature used to work in a certain way but it no longer does even though it should. and removed Can't reproduce (yet) For issues that are reported by several people, but can't be reproduced reliably and need more data labels Dec 3, 2020
@sgiehl
Copy link
Member

sgiehl commented Dec 3, 2020

I was able to reproduce that. The problem is that this widget tries to send API requests forcing a session usage, which fails widgetized. Will check if there is a easy solution

@sgiehl sgiehl added this to the 4.0.3 milestone Dec 3, 2020
@sgiehl sgiehl self-assigned this Dec 3, 2020
@sgiehl sgiehl mentioned this issue Dec 3, 2020
Merged
9 tasks
@tsteur
Copy link
Member

tsteur commented Dec 3, 2020

@sgiehl as mentioned in the PR it should fix it for widgets but we still need to check if it affects also embedding regular controller actions as some users seem to do that

@sgiehl
Copy link
Member

sgiehl commented Dec 4, 2020

I will check that now

@sgiehl
Copy link
Member

sgiehl commented Dec 4, 2020

@tsteur that is still a problem, and generates brute force entries. I'm not sure what the best solution would be.
Should we maybe revert the changes done for the widgets, but instead change the api authentication to first check if the token can be used without the session and only if that is not possible force a session usage.

Other possibility would be to change the widgetize check I've added and check if the token_auth is given in the url instead of checking for the Widgetize module.

@tsteur
Copy link
Member

tsteur commented Dec 6, 2020

@sgiehl ideally we avoid this if any possible as it should be better to exactly check a value against a session vs token etc. I'd need to think a bit more but if really needed we could do it.

What about: If the actual URL includes token but no force_session_api then we don't set the force_session_api? If no token is included or force_session_api=1 in url then we do send force_session_api. Would that work?

@sgiehl sgiehl mentioned this issue Dec 7, 2020
Merged
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sgiehl sgiehl

Labels
Regression Indicates a feature used to work in a certain way but it no longer does even though it should.
Projects
None yet
Milestone
4.0.x
Development

Successfully merging a pull request may close this issue.

Assume something is widgetized whenever a token_auth is set in url matomo-org/matomo
3 participants
@tsteur @sgiehl @olinox14