Yup, this is a nicely executed instance of what's called a Picture-in-Picture attack: https://textslashplain.com/2017/01/14/the-line-of-death/

Do you have any novel ideas about how a browser might combat an attack of this nature?

Deleted: PiP.png 113 KB

	PiP.png 113 KB View Download

Well yes actually. Challenge accepted! But first, I mentioned I thought this was a PayPal only issue - but it appears Google accounts are even easier to fake.

See http://usekp.com/c/dave1/google as another example. In this case, I even added some (crappy) sounds when the user clicks outside the dialog box, further cementing the idea that is a system, rather than a browser dialog box that is appearing. And you can't get rid of it, like a normal browser dialog. Can't go back, or forwards, and in fact, at the end, it loads the Google search page, and you can't go back to the page that phished you because I used a location.replace to get to the Google Search Page. Assuming the user was logged into Google Chrome at the beginning, they will really have no idea they were phished.

I would say that important pages - ones like PayPal or the Google pages that can collect account details should not be able to be launched in other than full screen windows. Or rather full window windows, so the URL bar is still visible. Otherwise it is too easy to fake. That is my initial thought. But I think, given a day or so, I could come up with several more. It was only a day or two ago I decided to sit down and see just how easy this whole thing was.

And in all of these simulations, I could have gone further than just picture in picture. I could allow the faked window to be moved around from the title bar. I already activated all the buttons in the simulated URL bar to make it seem alive and real. Adding the background sounds when they click outside the faked dialog box as I mentioned also makes it seems more realistic. It all happens on one web page so there and everything is preloaded so there is no delays or no new web pages being loaded (prevents back button being used). I considered using the Full Page API as mentioned in that link, but in both cases that is not even needed for the simulation to be accurate. On the Google example I could have used more animations to make it more realistic, but I think that would also have been overkill.

Deleted: chrome.jpg 48.1 KB

	chrome.jpg 48.1 KB View Download

> should not be able to be launched in other than full screen windows.

Can you elaborate on why you believe that this would meaningfully address picture-in-picture attacks? Normal web users wouldn't know that such a special limitation exists, which means that they wouldn't know that a page that wasn't full-screened was not legitimate.

(That's setting aside, for now, the difficulty of the browser somehow detecting legitimate login pages and forcing them to run in full-screen).

Give me a few days - I'll have some great ideas. I know browsers inside out and the issues and limitations you face in this regard.

I'm going to close this bug to remove it from the security queue, since it's a well-known/public limitation of web browsers and computing systems in general. To the reporter: if you have other ideas that would improve user security in these situations, please file them as new feature requests. Thanks!