Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cross Site Scripting Discovered in Google

Posted by CmdrTaco on from the hate-when-that-happens dept.

Security Test writes "Yair Amit posted a message early this morning to The Web Security Mailing List outlining a Cross Site Scripting flaw in Google that allows an attacker to carry out Phishing Attacks."

2 of 158 comments (clear)

  1. Advantage of online applications by G4from128k · · Score: 5, Interesting
    This example illustrates the advantages of web applications. Google was able to patch the flaw and roll it out to 100% of the user base in a short time period. Providing applications online means centralized version control and patching -- there's no waiting for all the users to patch.


    The downside is that this only works if the app provider is a proprietary vendor with a closed architecture. If 3rd parties are allowed to create extensions or if users can create their own utilities/add-ons then centralized patching would likely introduce the same types of incompatibilities and breakages that current OS patches can introduce. Worse, centralized control might mean that users have no choice but to live with the patched version.

    --
    Two wrongs don't make a right, but three lefts do.
  2. Cross-Site Scripting for Internet Explorer by Anonymous Coward · · Score: 5, Interesting

    This is reported as a Google.com bug, which is partially true. But this is only one half of the problem. The other half of the problem (mentioned in the full article) is due to a dubious feature in Internet Explorer: when it gets a page without a specified character encoding, it does not rely on default values for the encoding (which should be iso-8859-1 for HTML or UTF-8 for XHTML).

    Instead, Internet Exploerer tries to guess the encoding of the contents by looking at the first 4096 bytes of the page and checking the non-ASCII characters. In the case of the cross-site scripting attack decribed here, the problem is that IE would silently set the encoding of a page to UTF-7 in case some characters in the first 4096 bytes looked like UTF-7. This silent conversion to UTF-7 by Internet Explorer in a text that Google assumed to use the default encoding allowed the attackers to bypass the way Google was filtering "dangerous" characters in some URLs.

    The article puts the full blame for the vulnerability on Google.com. I think that a part of the blame should also be shared by the Internet Explorer designers (and any other browser that does unexpected things while trying to guess what the user "really meant").