Hi Tim First of all, the dialog spoofing issue still works in Google Chrome and it has not been patched. A lot of tests have been conducted considering different variants spoofing. I missed your paper previously. I must say its a very good read. A similar issue about Google URL obfuscation, which still persists because it has been mentioned by the team itself some stuff is based on the standards of HTTP protocol handler authentication schemes (http://www.nice.com@xxxxxxxx). The link is as follows http://code.google.com/p/chromium/issues/detail?id=4739 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 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 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. Kind Regards Aditya Tim wrote: > Hi Aditya, > > >> Google Chrome ( 5.0.375.127 and previous versions) suffers from HTTP >> Auth Dialog spoofing vulnerability due to possible >> realm manipulation in the HTTP header. Previously, Google chrome has got >> a similar bug which can be seen on the following link >> > > > How is this significantly different than the issues described in: > http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf > ? > > See the section on page 11 entitled "Weak User Interfaces for HTTP > Authentication" > > In your video, I didn't see precisely what realm string was sent or > what the overall auth header was, so it's hard to tell. Also, it may > be that variants of these attacks still work in Firefox. > > Note that the above paper was sent to all major browser vendors around > the time that Google was notified about (and fixed) this bug: > http://code.google.com/p/chromium/issues/detail?id=32718 > > tim > >
