Remote extraction of passwords from browser password managers

Question

I'm writing an essay about "Browser Password Managers". As part of this I have to write about vulnerabilities and exploits. I stumbled across the following scientific paper from 2013: "Password Managers: Attacks and Defenses by Silver et al." (https://crypto.stanford.edu/~dabo/pubs/papers/pwdmgrBrowser.pdf), which describes in section 4 "Remote extraction of passwords from password managers". I don't know if the described "sweep attacks" are still possible today, like in Chrome Browser? What about the same-origin-Policy?

Answer 1

Concept of "origin"

The "same origin policy" can only be as robust as the definition of an origin is. The origin is the entity the browser believes it talks to.

Quoting the paper:

Next, by tampering with network traffic the attacker (...)

The idea that you can modify at least some server answers makes the origin of these vulnerable requests meaningless for security: if tampering is possible at all, it means that some (formal) "origins" don't correspond to the entity the browser is actually talking to; instead the browser is talking to the attacker, while believing it's talking to the legitimate HTTP server.

Without at least integrity of exchanged data (let's put privacy aside for a moment), you don't even have an origin.

(Of course without secrecy of the exchanged data, your password might be captured by an attacker when you log, so both integrity and secrecy matter.)

Note: These security properties doesn't have to come from robust cryptography, you could also log on a server on localhost with clear text HTTP. The OS will prevent the interception of the data on the TCP socket that uses only local routing.

If you don't have a well defined robust origin, you can't expect any protection from the browser mechanisms based on the origin.

When dealing with a remote server, with HTTP, and without lower level protections like IPsec or a secure tunnel protocol to the server, your data is vulnerable and "origin" is ill defined.

The most common vulnerable situation is using http: URLs on an open Wifi, but using the same URLs via a commercial "VPN" also exposes you, but not to the same party: using Wifi exposes you to local attacker (mostly an attack from the owner of the Wifi access point, but not only); using a "VPN" service exposes you to the manager of that service (who can spy on you).

Sound design of public websites (not private tools on an intranet) that deal with private information require the use of HTTPS. The paper insists on the fact that this is far from universal (at least when the study was done):

It is especially easy for sites that serve their login page over HTTP (but submit passwords over HTTPS), which is a common setup discussed in the next section.

Hosting a "secure" form (one that sends data on a secure URL) on an insecure page is fundamentally, absolutely, definitely unsound. All webmasters should know that. Sadly it isn't the case as understanding of even the most basic facts of the security model isn't required from people who design websites.

Any HTTP request over the Internet is exposed to spying and tampering. Many ignorant Web page designers believe that "secure transport" (HTTPS, TLS) is only for secret data and is a significant and useless overhead for inherently non secret data, like the content of a login form (anyone can see the same login form).

And because they misunderstand the scope of "secure transport" they might put pages that inherently cannot contain private information on an insecure http: URL, making these vulnerable to tampering (and also spying on the who downloads that login page, but that one isn't usually a real concern).

The idea that "https:" URLs only exist for secrecy of informations exposed on a particular page, and the others can be in "http:" must die.

Sub-resources

Also don't forget that any Web page which includes any element that is allowed to contain Javascript code that runs in the context of the page is vulnerable to tampering, so this isn't limited to tampering with the HTTP content of main URL shown in the browser address bar; making HTTPS pages that include JS scripts or even CSS content loaded via HTTP is fundamentally unsound and modern browsers rightly refuse to load these insecure elements by default.

Special permissions for websites

You can't associate a meaningful "privileges" (or permissions) to an "origin" (like the right to access your webcam or your gyroscope) if the origin is insecure and can be usurped by an attacker with network access. That's why modern browsers restrict the permissions that an insecure origin can ask (or limit these privileges in time).

Human factor

It should be understood that these concepts aren't advanced or reserved for security professionals: they should be part of the basic common knowledge of at least all Web designers, and if possible of all users. It should be considered as elementary and obvious as "you don't start a car when the windshield is obstructed by an anti sun anti heat cover".

I didn't want to discuss psychology but there is a strong human factor that I want discuss here because that's what I see as one common reason for failure to take basic security measures.

One practical problem with computers and people is the often dismissive attitude that people who don't have even elementary knowledge have with respect to such knowledge; they often say that "they aren't experts, don't want to be, don't have the time to learn a lot" and "just want to get a job done" (probably as opposed to purists?) - as if more knowledgeable users were just pedants who wanted to have encyclopedic knowledge of computers, had unlimited time, or would want to get nothing done ever but in the most pure and elegant way. I know some people who have encyclopedic knowledge and allocate a lot of time to learn more, but they also want to get some task done (if only: to get to learn even more, which is a task).

Nobody wants nothing done ever, but that "nothing" done in the "purest" way. That's an oxymoron as getting anything done in the purest and most beautiful way would actually get something done and over. The frankly insulting undertone of these remarks is why some people never learn and why other give up on explaining how to properly use a computer to others (that is, to use it to something done).

Like any activity, using a computer for anything, including something as common as setting up a website, requires at least understanding of some basics. But when dealing with computers, almost nothing is really intuitive and we need to explain stuff without sounding pedantic.

Also for websites with millions of users, we need name and shame. Designing a website that doesn't even respect the most basic security principles should be seen as equally inane as driving with the windshield entirely obstructed, and pointing out the inanity of that conduct shouldn't be seen as pedantic.