@trimbz opened this Issue on August 5th 2019

We recently had a vulnerability assessment which highlighted the following vulnerability in Matomo :-

The Matamo login page does not perform a redirect after the user's credentials are sent to it. Valid login requests will have the server respond with a 200 OK rather than a 302 Redirect.

This means that this page can be refreshed in the browser and the credentials will be resent to the application. In a shared computer environment this can leave the user's credentials vulnerable to replay attacks or disclosure.

The response that is returned to the user after the login credentials have been sent should be an HTTP 302 redirect to the page that the application wishes to display. This will prevent the login credentials from being resubmitted if this page is refreshed because the redirected page will be
reloaded instead. The following HTTP headers would achieve this:

HTTP/1.1 302 Redirect

Note that a redirect should be added to any page which receives sensitive information to prevent requests being cached.

@Findus23 commented on August 5th 2019 Member


  • I get that doing POSTs without redirect can lead to confusion and bad UX
  • In my test Matomo does a 302 redirect:

  • even if it didn't I have no idea how this can be used as an security issue (apart from being anoying in some cases)
    If an attacker can access the computer and reload the page they have tons of other possibilities to take over the account (run a keylogger, read the memory where the browser stored the POST data, watch the user enter the password, install a MITM cert to intercept the HTTP request, hit the user until they tell them the password, read the session cookie from the browser, etc.)

Can you please further explaine what isn't working in your Matomo instance?

@trimbz commented on August 5th 2019


I just tried to replicate the issue on our current version of Matomo and it seems to be working as expected, giving a 302 redirect on login. So either this has been fixed in the last Matomo update I put on or our vulnerability assessor has given me a bum steer. Either way, big apologies I should have confirm the assessment was right before I submitted this ticket. I'll close this ticket.

This Issue was closed on August 5th 2019
Powered by GitHub Issue Mirror