XSS Analysis in the accounts.google.com domain with 7500 knives

GOOGLE's XSS has now risen to 3100 ~ 7500. Then, a well-known Japanese simplified stream sent an xss in the accounts.google.com domain. on Weibo, I saw @ xisigr sending a link on Sina Weibo and I went to see it, although I cannot understand Japanese, I still analyzed it.

Original article link: Masato Kinugawa Security Blog: accounts.google.com contains zookeeper XSS

The specific analysis is as follows:

The original defect address is:

https://accounts.google.com/NewAccount?oe=utf-32&Email=%E2%88%80%E3%B8%80%E3%B0%80script%E3%B8%80alert%281%29%E3%B0%80/script%E3%B8%80

According to my understanding, the oe parameter should be used to specify the output encoding of the field, and the email is the input. After the encoding specified by oe is converted, output to <input type = "text" value = "[Email]"/> of the page.

To put it simply, if we input AAAAAA, oe = gbk via Email, AAAAAA --> is converted to gbk encoding --> [AAAAAAA] Under GBK encoding, output to the page.

As a result, the discoverer of the vulnerability was a zombie...

According to the author's ideas,

1. First, set the output encoding to a UTF-32.

In the UTF-32, each 4 bytes represents a character, such

Double quotation marks --> [0x00] [0x00] [0x00] [0x22] <parentheses --> [0x00] [0x00] [0 x 00] [0x3C]> brackets --> [0x00] [0x00] [0x00] [0x3E]

So more fun is, in the UTF-32, it is also a valid character:

[0x00][0x00][0x22][0x00] --> ∀ [0x00][0x00][0x3C][0x00] --> 㰀 [0x00][0x00][0x3E][0x00] --> 㸀

So if we use the above three "weird" characters to replace double quotation marks and angle brackets, what will happen?

"<script>alert(1)</script>

Change

∀㸀㰀script㸀alert(1)㰀/script㸀

2. Then: too many characters script into alert (1) characters/script encoding, after being converted to UTF-32 encoding, the output to the UTF-8 encoding page will be output in the form below:

[0x00][0x00]"[0x00][0x00][0x00]<[0x00]script[0x00][0x00]>[0x00]alert(1)[0x00][0x00]<[0x00]/script[0x00][0x00]>[0x00]

3. in IE10 or earlier versions (IE9 is not tested, and IE9 is in the original text, which can be executed), [0x00] in HTML will be ignored, as a result, the above code is executed as a common HTML.

Null Byte [0x00] will not affect the execution of the above Code, see the demo: http://xsst.sinaapp.com/nullbyte.htm

4. In order to see this vulnerability more intuitively, we have written a PHP page for you to experiment on your own.

http://xsst.sinaapp.com/utf-32-1.php?charset=utf-32&v=%E2%88%80%E3%B8%80%E3%B0%80script%E3%B8%80alert(1)%E3%B0%80/script%E3%B8%80