Password manager clickjacking

[Alan Karp]

Thanks for the pointer.  I had a lovely afternoon checking SitePassword.  Most of the attacks don't apply because SitePassword doesn't store things like credit card numbers.  It also doesn't use web-accessible-resources.

SitePassword was vulnerable to two of the opacity attacks because window.getComputedStyle() reports the opacity is 1 when it is visibly 0.5 on the page.  One of them I fixed by checking ancestors (I thought that's what computedStyle did), but I'm stuck on the other one,

https://websecurity.dev/password-managers/dom-based-extension-clickjacking/overlay/visible/

The problem is a popover that covers the entire page.  The login form has visible opacity 0.5 even though it's not contained in the popover nor is it under it.  The z-index for both is NaN.  However, the popover is after the login form in the HTML.

I'm not too worried about it because the attacker has to be able to modify the page with the login form.  If that's possible, there are lots of other things that can go wrong.  Still, it would be nice to fix the problem.

--------------
Alan Karp

[James Diacono]

Attempting to detect the stacking order of elements is very ambitious, I hope you are not attempting that. The rules are extremely complex.

[Alan Karp]

On Sat, Aug 30, 2025 at 2:28 AM James Diacono <diach...@gmail.com> wrote:

Attempting to detect the stacking order of elements is very ambitious, I hope you are not attempting that. The rules are extremely complex.

As I learned.  However, there are heuristics I can use to infer malicious intent.  

For example, there is no legitimate need to make the opacity of a password field less than 1, so I don't attach the onclick handler to it.  In the example I linked to, there is a popover with width and height 101%.  It doesn't appear there is a legitimate need for that on a login page.  My holdup now is figuring out what other kinds of elements act like a popover.  The nice part is that if I get it wrong, you can still copy/paste your password.

--------------
Alan Karp

[๏̯͡๏ Jasvir Nagra]

Element.checkVisibility() is your friend.

-- 

Jasvir Nagra

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z25a9NDgqO2gR9dCeLOSRO9SB6whnJPEZ7WHiGE9D2Pfg%40mail.gmail.com.

[Alan Karp]

On Sat, Aug 30, 2025 at 11:44 AM ๏̯͡๏ Jasvir Nagra <j...@nagras.com> wrote:

Element.checkVisibility() is your friend.

I'd call it an acquaintance.  It doesn't check a lot of ways to hide an element, 

1. under something 
2. off screen
3. opacity = 0.001

Is it better than window.getComputedStyle(element) for what it does check?

In any case, just testing for visibility doesn't solve the 

https://websecurity.dev/password-managers/dom-based-extension-clickjacking/overlay/ 

clickjacking attack.  The element is visible and on top, but the popover means that you can't see the element on the screen unless it has a contrasting background.  I don't understand why the boxes around the input fields aren't visible.

--------------
Alan Karp