Re: Google Chrome: HTTP AUTH Dialog Spoofing through Realm Manipulation (Restated)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Aditya,

> 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:
> 
> http://code.google.com/p/browsersec/wiki/Part3#HTTP_authentication

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
> :http://aviv.raffon.net/2008/01/02/YetAnotherDialogSpoofingFirefoxBasicAuthentication.aspx

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
domain).


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

thanks,
tim



[Index of Archives]     [Linux Security]     [Netfilter]     [PHP]     [Yosemite News]     [Linux Kernel]

  Powered by Linux