lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 Aug 2010 17:05:29 -0700
From: Tim <>
To: Aditya K Sood <>
Subject: Re: Google Chrome: HTTP AUTH Dialog Spoofing through Realm
 Manipulation (Restated)


> First of all, the dialog spoofing issue still works in Google Chrome and
> it has not been patched. 

I'm not surprised.  There didn't seem to be a lot of interest in these
issues from any browser vendor when I brought them to their attention.

> A lot of tests have been
> conducted considering different variants spoofing. I missed your paper
> previously. I must say its a very good read. 

Not a problem; the paper only addressed this topic tangentially.  I
only brought it up because I wasn't sure how things had changed since
I last tested and thought you could enlighten me.

> Further, it has been mentioned several times that it is a legitimate
> attack point used by phishers. For example:

Yup, the attack scenario I described came straight from the BSH,
though I didn't mess around with the password-in-URL stuff.

> Even this issue is not patched. May be URL protection like Mozilla is a
> good practice.
> Further, Mozilla has worked pretty fine after the dialog spoofing
> vulnerability disclosed by Aviv Raff on below mentioned
> link
> :

Ah, nice, I didn't see this one when I was last testing this stuff.

> We have used a well defined PHP script in this demo combining with a URL
> obfuscation issue. Since spoofing aims at
> manipulating the security features in user interfaces, it requires a new
> model dialog for HTTP authentication that should disseminate
> the realm value from domain name. Restricting, the string length of
> Realm value could be a good lead here.

More usefully, the realm should be clearly separated from the domain
and labeled in the dialog like Opera does it.  See the screenshot of
that in my paper.  There could still be some confusion, but it's
clearly much better than trying to embed potentially malicious strings
within the same sentences as more carefully validated ones (the

So, once again, could you send the realm string/auth header you were
setting in that demo?


Powered by blists - more mailing lists