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

Cached Post-Login Page Permits Re-sending User Credentials Vulnerability #14733

Closed
trimbz opened this issue Aug 5, 2019 · 2 comments
Closed
Labels
not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org.

Comments

@trimbz
Copy link

trimbz commented Aug 5, 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
Location:
http://example.com/app/landing-page

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

@Findus23
Copy link
Member

Findus23 commented Aug 5, 2019

Hi,

  • I get that doing POSTs without redirect can lead to confusion and bad UX

  • In my test Matomo does a 302 redirect:
    image

  • 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
Copy link
Author

trimbz commented Aug 5, 2019

Hi,

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.

@trimbz trimbz closed this as completed Aug 5, 2019
@mattab mattab added the not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org. label Oct 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
not-in-changelog For issues or pull requests that should not be included in our release changelog on matomo.org.
Projects
None yet
Development

No branches or pull requests

3 participants