Respect XSS: October 2015

Recently (22-10-2015), I found a Cross-Site Scripting (XSS) in YouTube Gaming. I was looking at the Twitter stream and came across the following tweet.

This tweet by @SwiftOnSecurity leads me to YouTube Red (sounds new service of YouTube) and from there I think I ends up on YouTube Gaming somehow :D I do not know about this sub-domain of YouTube before.

The XSS was in script context and in the site’s main search bar (search_query GET parameter was vulnerable). In order to keep it simple (though script context may be further divided into areas like JavaScript String Literal, JSON, Function Call and Conditional Statements etc), I call it script context in general because input reflects back in the script block i.e., <script> Input Reflection Here </script>.

As soon as I opened the YouTube Gaming site, literally it took me 2 minutes to find this XSS. Before using the final attack payload (simple, well known and effective), I injected the following probe string (I can write few pages on the importance of the probe string given below but for the moment I will leave this up to you to think on that) …

"xxxxxxxx'yyyyy</img

The above probe string on YouTube Gaming site reflects back on the page 12 times (8 times as a part of content attribute of <meta> tag while 4 times inside the script block). The YouTube Gaming site is doing good in controlling the potentially dangerous characters (i.e., ", ' and </ ) that're part of probe string except one time in script block where I found </ reflected back without encoding/escaping. The URL looks like the following at the time of probe:

https://gaming.youtube.com/results?search_query="xxxxxxxx'yyyyy</img

The following Figure shows the reflection of probe string in script context on YouTube Gaming page.

It is clear from the above Figure that reflection 1 and 3 are of no interest for us. In the first reflection (#1 in Figure, marked in red box) in script block, ", ' and < are in URL encoded form i.e., %22, %27 and %3c respectively while forward slash (/) is escaped (\/). In the third reflection (#3 in Figure, marked in red box), " and / are escaped (i.e., \" and \/) while < is converted into its Unicode encoded form i.e., \u003c. The second reflection (#2 in Figure, marked in red box) is of our interest because " are escaped (\") while developers forgot to control </. If you see/observe that during the reflection in an script block if </ are not controlled by developers or they forgot about it then you can prematurely closes the script block (e.g., </script>) and do what ever you will wish. As soon as I realized that </ are not controlled then as a part of next attempt (i.e., in total this was just a second attempt while the first attempt deals with the probe string and please keep in mind that there was no involvement of any tools like Burp Suite. ) I used the well known XSS attack vector.

</script><script>confirm(document.domain)</script>

The URL looks like the following:

https://gaming.youtube.com/results?search_query=</script><script>confirm(document.domain)</script>

Here is the screen-shot I recorded:

The payload (</script><script>confirm(1)</script>) is so powerful that I recently found XSS in NetFlix and Yandex Image & Video Search via it. In both NetFlix and Yandex, double quotes (") are properly escaped in script block while developers forgot about </. I have at least 10 more real examples from top sites where developers forgot about </.

The Figures shows the probe string (mentioned earlier in the write-up) in NetFlix and Yandex respectively. In both Figures you will find " are escaped while </ is not.