Hi Tim You can have a look at the screenshot at below mentioned link http://www.secniche.org/goog_chr_auth_spoof.jpg Kind Regards Aditya Tim wrote: > 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 > > >