3 ms·

Seems like a nice subtle way to hijack the changing password mechanism, particularly on a sub-domain you control. Just set the URL to e.g. "https://evilsite/cha

Seems like a nice subtle way to hijack the changing password mechanism, particularly on a sub-domain you control. Just set the URL to e.g. "https://evilsite/changepasswords" https://evilsite/changepasswords" and wait for Password Managers to be updated. The fact that the spec says nothing about where a user can be redirected, and which domains/sub-domains are within scope for which change password requests seems like an oversight. For example if my password manager saves a password for login.example.com, is a .well-known/Change-Password on evil.example.com, or example.com in scope? Who decides? Is it left to the password manager to figure out the security scope?

CGamesPlay 8y ago
Well, since password managers already tie a password to a specific domain, presumably they would use the same logic for determining the scope of the well-known URL. I do agree that the spec could probably benefit from clarifying this, but I bet "the same domain as one of the recorded login URLs" is sufficient. (And the password manager would never even know to check evil.example.com if you hadn't ever put that password into that subdomain).
- Someone1234 8y ago
  > but I bet "the same domain as one of the recorded login URLs" is sufficient. What is that a quote from? I cannot find it in the spec here: https://wicg.github.io/change-password-url/index.html https://wicg.github.io/change-password-url/index.html
  - CGamesPlay 8y ago
    Sorry, intended as a hypothetical suggestion, not a quote.
    - Someone1234 8y ago
      Oh understood. Yeah that suggestion would fix my concerns almost wholesale. They just need to think about scoping it to e.g. domain, subdomain, etc.
- zeroimpl 8y ago
  Changing your password for a google account seems to involve going to myaccount.google.com (which is not the domain your login is associated with) - so clearly this needs to support redirects to different subdomains.
Ajedi32 8y ago
I don't understand your concern. If the attacker controls `https://example.com/.well-known/change-password` https://example.com/.well-known/change-password` wouldn't they also control `https://example.com/my_profile/settings` https://example.com/my_profile/settings`? Why bother redirecting the user to a third party site when you can just inject some password-logging JS into the _legitimate_ change password form?
- pmontra 8y ago
  Not necessarily. They can be on two different servers behind a reverse proxy, or the attacker can only write to static files or anything else.
- Someone1234 8y ago
  If an attacker controls a subdomain and can trick a user into visiting it (e.g. evil.example.com), the cookies may be out of scope, but the password manager may (or may not) treat the subdomain as part of the domain in terms of .well-known/change-password requests, allowing a subdomain to redirect the password manager and potentially stealing credentials. It is undefined behaviour. The spec is under-defined. That's my issue, there has been no security pass of this at all. It is left up to each individual password manager to make this secure (or not).
  - therealtbs 8y ago
    I assume the password manager is supposed to prepend the host of the login form or whatever host is configured in the password manager. So if I save example.com in my password manager, it will access example.com/.well-known/change-password no matter which urls I later visit that might be on subdomains of that original page. If I already configured evil.example.com in my password manager, it's game over anyway before anything relevant to this spec even happens.
  - Ajedi32 8y ago
    I still don't see your point. If your password manager autofills your credentials for `example.com` when you visit `evil.example.com` then the owner of `evil.example.com` already has an easy way to steal your credentials regardless of whether or not this spec is implemented.
hober 8y ago
This is being tracked by https://github.com/WICG/change-password-url/issues/8 https://github.com/WICG/change-password-url/issues/8

CGamesPlay 8y ago

Well, since password managers already tie a password to a specific domain, presumably they would use the same logic for determining the scope of the well-known URL. I do agree that the spec could probably benefit from clarifying this, but I bet "the same domain as one of the recorded login URLs" is sufficient. (And the password manager would never even know to check evil.example.com if you hadn't ever put that password into that subdomain).

Someone1234 8y ago
> but I bet "the same domain as one of the recorded login URLs" is sufficient. What is that a quote from? I cannot find it in the spec here: https://wicg.github.io/change-password-url/index.html https://wicg.github.io/change-password-url/index.html
- CGamesPlay 8y ago
  Sorry, intended as a hypothetical suggestion, not a quote.
  - Someone1234 8y ago
    Oh understood. Yeah that suggestion would fix my concerns almost wholesale. They just need to think about scoping it to e.g. domain, subdomain, etc.
zeroimpl 8y ago
Changing your password for a google account seems to involve going to myaccount.google.com (which is not the domain your login is associated with) - so clearly this needs to support redirects to different subdomains.

Ajedi32 8y ago

I don't understand your concern. If the attacker controls `https://example.com/.well-known/change-password` https://example.com/.well-known/change-password` wouldn't they also control `https://example.com/my_profile/settings` https://example.com/my_profile/settings`? Why bother redirecting the user to a third party site when you can just inject some password-logging JS into the _legitimate_ change password form?

pmontra 8y ago
Not necessarily. They can be on two different servers behind a reverse proxy, or the attacker can only write to static files or anything else.
Someone1234 8y ago
If an attacker controls a subdomain and can trick a user into visiting it (e.g. evil.example.com), the cookies may be out of scope, but the password manager may (or may not) treat the subdomain as part of the domain in terms of .well-known/change-password requests, allowing a subdomain to redirect the password manager and potentially stealing credentials. It is undefined behaviour. The spec is under-defined. That's my issue, there has been no security pass of this at all. It is left up to each individual password manager to make this secure (or not).
- therealtbs 8y ago
  I assume the password manager is supposed to prepend the host of the login form or whatever host is configured in the password manager. So if I save example.com in my password manager, it will access example.com/.well-known/change-password no matter which urls I later visit that might be on subdomains of that original page. If I already configured evil.example.com in my password manager, it's game over anyway before anything relevant to this spec even happens.
- Ajedi32 8y ago
  I still don't see your point. If your password manager autofills your credentials for `example.com` when you visit `evil.example.com` then the owner of `evil.example.com` already has an easy way to steal your credentials regardless of whether or not this spec is implemented.

hober 8y ago

This is being tracked by https://github.com/WICG/change-password-url/issues/8 https://github.com/WICG/change-password-url/issues/8