Malicious subdomain concern

[hober]

This was raised on public-webappsec:

I am also concerning that draft is not considering 3rd level domains take over and how an attacker could advertise a password change URL to get a Beef kind of hooking of clients in a bot fashion.

[rmondello]

I’m confused as to what’s special about the change password URL with malicious subdomains. If the user and their password manager had reason to send them to that malicious subdomain in the first place, what difference does a special path on that domain make?

[tag636]

The point isn't about a malicious domain, but a legit one, example site.test and an attacker taking over test.site.test and redirecting site.test changing password to the 3rd level test.site.test that just got taken over from legitimate owner. It is happening often on cloud services

[tschoffelen]

I wonder about the practicality of that though. A password manager will only query the change-password URL for a site you have stored, so only if the user is already signing in to a malicious website, this would be a concern, right?

Example: I create malicious-subdomain.freewebsites.com on a free website-maker platform. The admin panel for that service is most likely on freewebsites.com or admin.freewebsites.com, so the only way I trick people into using https://malicious-subdomain.freewebsites.com/.well-known/change-password is if I get people to sign in on that specific subdomain and save those login details to their password manager.

Any other users of the service would store credentials for freewebsites.com or admin.freewebsites.com in their password manager, so there would be no reason for the password manager to ever query https://malicious-subdomain.freewebsites.com/.well-known/change-password.