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

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

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


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


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

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

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