How did Masato find the Google Search XSS?
Articles Blog

How did Masato find the Google Search XSS?

Wow, the video about masato’s Google Search
XSS, was the most shared video I have ever made. I’m really happy that so many people appreciate
the ingenuity in it, even though many people would say “it’s just a XSS”. So I thought we could talk about how masato
found this XSS and use it as an example for how security research can look like. Maybe you can also start doing some research
yourself. Let’s first start with a tweet gareth shared
in 2017, about a very similar weird behaviour he noticed, which basically looks like Masato’s
XSS, just with noembed – At that time mikewest also responded that noscript works too. You should know that mike west is heavily
involved in the World Wide Web Consortium (W3C). So he is a person who has real influence on
the web. And so he wrote about noscript that
This is what the spec says should happen but I wonder if we should change that. :/ So mike west and gareth found this kind of
behaviour interesting back in 2017. gareth actually found that noembed mutation
when researching Cloudflare’s HTML parser. You can read more in that blog post over at
portswigger. And then also responded to gareth’s tweet
saying: I often use this trick when I attack any server
side sanitizer. That’s what I was saying last video about
server side sanitization. The problem is that there could be parser
differentials between a server side parser versus what the browser actually parses. And by the way, the idea of attacking different
parser behaviours is a fundamental idea in IT security research. I have even made a video in 2016 introducing
that concept as part of the binary exploitation playlist. So that kind of thinking during research is
not uncommon. But masato also added that:
I didn’t know that the inconsistante state happens via “JS APIs” until recently. Did you know that? 🙂 So even though he is super experienced, he
apparently didn’t realize that parsing with javascript functions can also be different. So masato has seen the browser and HTML parsers
doing weird stuff all the time. And he told me that there were two behaviours
that he observed that ultimately lead him to the discovery of the XSS. The first observation had to do with iframes. He said that a FEW YEARS AGO he was testing
and playing around with iframe sandboxing and the HTML noscript tag. The Sandbox applies extra restrictions to
the content in the frame. The value of the attribute can be empty to
apply all restrictions. And you can see in the sandbox options. You could allow javascript in the iframe with
“allow-script”. Or if you didn’t use the sandbox attribute
at all. Which means in this case, with an empty sandbox
attribute, the iframe content cannot execute javascript. As you can also see there is a “srcdoc”
attribute. Which is Inline HTML to embed
So this simply creates an iframe with this content. Let’s copy that iframe and also allow-scripts. And then we have a look at it in the browser. So here we have the two worlds. A world with javascript enabled and a world
with javascript disabled. As we know since last video, this is what
we expect the behaviour of

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top