Shibuya.XSS JIZEN-GAKUSHU Challenge

This challenge was posted by Masato Kinugawa in March 2016, accompanying the Shibuya.XSS event in Tokyo.

URLs

• http://shibuya.vulnerabledoma.in/jizen (Challenge Website)
• http://shibuyaxss.connpass.com/event/28232/ (Event Website)
• https://speakerdeck.com/masatokinugawa/shibuya-dot-xss-techtalk-number-7 (Slides by Masato)

Solution

The model solution created by Masato Kinugawa:

http://shibuya.vulnerabledoma.in/jizen#mhtml:http://shibuya.vulnerabledoma.in/jizen/">%3Csvg%20onload=alert(1)%3E

Note: You have to use unencoded characters instead of %22 and %3c, copy&paste might break the PoC. You can also click here to play with the PoC: http://is.gd/6KL7sV

Tested and confirmed on MSIE11 and Edge (!).

Why does that work?

There is several reasons why this works, and several tricks being used to attack the seemingly secure page:

• First of all, jQuery mobile performs a navigation that is supported by the use of history.pushState()
  • Check out the jQuery Mobile docs about hashListeningEnabled and pushStateEnabled: http://demos.jquerymobile.com/1.0/docs/api/globalconfig.html
• This is not a bug in itself, but combined with the existing JavaScript on the page, it becomes a vulnerability
• As can be seen, on the website, a "tracking image" is built, using location.pathname
• Combining history.pushState() with a mhtml: protocol handler allows to inject unencoded payload into the location.pathname property
• So, first the jQuery mobile framework "navigates" to the new URL, then the now infected location.pathname property will be used to create a HTML element
• Given the lack of encoding, we can now break the HTML string and create an active element. Aaaand, XSS.

Challenge solved :)