Password reset key leaked via HTTP "Referer" field
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mahara |
Fix Released
|
Low
|
Robert Lyon | ||
1.10 |
Fix Released
|
Low
|
Robert Lyon | ||
1.8 |
Fix Released
|
Low
|
Robert Lyon | ||
1.9 |
Fix Released
|
Low
|
Robert Lyon | ||
15.04 |
Fix Released
|
Low
|
Robert Lyon |
Bug Description
If a site has resources on external domains, and a user clicks the link in a "forgot password" email, then the key to reset their password gets sent to those external domains via the "Referer" field of the HTTP request. External resources could be from the Persona plugin (which loads up a javascript file from the main Persona server), from the $CFG->additiona
To replicate:
1. Turn on the Persona authentication plugin
2. Log out of Mahara
3. Click the "Lost username / password" link
4. You'll receive a password reset email. It will contain a link like this: "https:/
5. In your web browser, turn on a tool that lets you view HTTP requests and their headers.
6. Load the password reset link
Result: You'll see the "key" param of forgotpass.php being sent to the persona.org servers:
Host=login.
User-Agent=
Accept=*/*
Accept-
Accept-
Referer=https:/
Connection=
The password reset process happens takes two page loads. The first page load displays the "new password" form to the user, and the second page load actually changes their password and expires the key.
So that means this is actually abuseable. An attacker who had a resource that gets included in each page load could, in theory, listen for that key in the referer field, and then quickly use it to reset the password themselves.
Low priority because this attack requires the attacker to have compromised the system already. And there's only a slim window of opportunity. They have to use the key after the new password screen is loaded, but before the user fills it out and submits it.
CVE References
no longer affects: | mahara/1.7 |
information type: | Private Security → Public Security |
Changed in mahara: | |
status: | Fix Committed → Fix Released |
I believe the best fix for this would be to remove the "key" from the URL before we render any page to the user. Like this:
1. User goes to https:/ /mahara. example. com/forgotpass. php?key= 3wKYEeGdBI2J5jS c
2. forgotpass.php reads the "key" param from the URL, stores it in the session, then redirects to https:/ /mahara. example. com/forgotpass. php
3. We proceed from there pretty much as normal.