Except if you find an XSS vulnerability in a site, you already have a serious security vulnerability that can be abused in many different ways to compromise a user. pushState simply makes one of those ways (phishing) more effective.
Personally, I'd rather take actions that don't require user interaction, like stealing the user's session cookie silently in the background or making other requests on their behalf to the website. That can be done via an invisible iframe on an otherwise legitimate website (which, I suppose, you could also consider to be "dangerous").
Comments
You cannot change the URL like that. URL need to be in same origin as the current URL to be changed.
You are correct. But the theoretical attack from "https://accounts.google.com/reallyuglyurl to "https://accounts.google.com/ServiceLogin remains on the same origin. So while what you say is true, it is not applicable for the example.
In the scenario outlined in the OP; an XSS on another www.google.com page is hypothesized:
once that hypothetical XSS is discovered, then the attacker can pushstate the page with the XSS to look like the login page...Except if you find an XSS vulnerability in a site, you already have a serious security vulnerability that can be abused in many different ways to compromise a user. pushState simply makes one of those ways (phishing) more effective.
Personally, I'd rather take actions that don't require user interaction, like stealing the user's session cookie silently in the background or making other requests on their behalf to the website. That can be done via an invisible iframe on an otherwise legitimate website (which, I suppose, you could also consider to be "dangerous").