Wacky XSS challenge write-up

First steps

Navigating to the challenge page hosted at https://wacky.buggywebsite.com/, the challenger was given a “simple” single input page. By entering text in the provided textarea element and clicking on the Make Whacky! button, the application provided the user with a funny looking version of the very same entered text.

Figure 1: Challenge page basic usage
Figure 2: Main page script.js file content

Dissecting frame.html

By navigating to https://wacky.buggywebsite.com/frame.html an error page stating that the frame.html content could only be viewed inside an iframe tag was displayed.

Figure 3: Iframe requirement error
Figure 3: window.name value check
Figure 4: Setting window.name value
Figure 5: iframe.html with window.name properly set
Figure 6: analytics.js file contents
Figure 7: Code branch responsible for loading analytics.js
Figure 8: window.fileIntegrity assignment

The first vulnerability

Once the page’s expected behavior was known, one could start playing around with the param query string parameter. As the main page was the one responsible for filtering the user input, by accessing the iframe.html file directly, one could then input potentially unsafe characters like &, *, <, >, and %.
After a few basic tests, one could verify that the contents of param were being reflected in the page’s title. By closing the title tag one was then able to inject arbitrary HTML content on the page.

Figure 9: Reflected XSS
Figure 10: Blocked by CSP

Bypassing CSP

In order to bypass CSP, one needs to first understand what are the page’s CSP rules. To do that, the challenger could have used the Network tab from Google Chrome’s developer tools. Inspecting the requests history, the CSP policy would be present in the content-security-policy header returned by the server.

Figure 10: CSP header
Figure 10: CSP warning
Figure 11: Relative file path
Figure 12: Mock Endpoint Builder
Figure 13: Flexible Redirector
Figure 14: Invalid SRI
Figure 15: Undefined fileIntegrity variable
Code snippet 1: SRI calculator
Figure 16: Calculating SRI

Out of the sandbox

By using the newly crafted URL the attacker would be faced with a new defensive mechanism, iframe sandboxing. The error message below would be displayed in the browser’s console.

Figure 16: Sandbox error message

The final payload

Finally, I came up with the following code:

Code snippet 2: Exploit Javascript code
Figure 16: Success message
Code snippet: Malicious page HTML markup


I would like to congratulate the BugPoc for setting up such an entertaining, educative, and well-constructed challenge. Also, once again, I would like to thank LiveOverFlow for all the incredible free content published.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Daniel Santos

Daniel Santos

Security researcher and penetration tester