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
Further, Mozilla has worked pretty fine after the dialog spoofing
vulnerability disclosed by Aviv Raff on below mentioned
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?