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.
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) …
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:
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.
The URL looks like the following:
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.
Here are the XSSes in NetFlix (https://twitter.com/soaj1664ashar/status/645532848250855424) and Yandex (https://twitter.com/soaj1664ashar/status/646188651207127040) in script contexts respectively.