XSS via the DOM

Go to this webpage with a parameter name in the URL, e.g.
http://www.cs.ru.nl/~erikpoll/websec/demo/xss_via_DOM.html?name=John.

The fragment of HTML below uses JavaScript in combination with the DOM to retrieve the parameter name from the URL to include include it in the content of the page. If you change the value of the parameter name, say from 'John' to 'Maria', the webpage show change.

Hello ! Welcome to this webpage.

You can now try to inject HTML mark-up tags, or even scripts, in the parameter name. For instance, try the links below:

• http://www.cs.ru.nl/~erikpoll/websec/demo/xss_via_DOM.html?name=<h1>test</h1>.
• http://www.cs.ru.nl/~erikpoll/websec/demo/xss_via_DOM.html?name=<script>alert('Let\'s try XSS via the DOM')</script>

Some things you can try:

• Alter the URL to change the effect of the script. Or see if you enter a name followed by a script, or multiple scripts.
• To try out some fancier JavaScript features: try to make a malicious URL that triggers a DOM-based XSS which opens a new tab in the victim's browser, and try to see if you can open multiple new tabs. See demo_DOM or DOM exercise for example JavaScript that will open new tabs.
• Send yourself an email with one of these XSS links, and see if your email client strips suspicious scripts from URLs inside emails when you click them. If it does, you could try to use a URL-shortener, such as https://tinyurl.com, to create a abbreviated URL will hide any script tags from the email client. This will also prevent people from seeing the suspicious script tags inside the link before they click on it.

You could use this webpage to do a reflected XSS attack, by creating a link like the ones above and then tricking a victim into clicking that link. But there is no interesting data or functionality on www.cs.ru.nl for scripts to abuse: the domain does not set valuable cookies to steal and it does not offer any interesting functionality that such an attack could trigger.

Defences against reflected XSS that used to be built-in browsers, such as XSS Filter in Edge and XSS auditor in Chrome, would strip any scripts from a webpage that are identical to scripts passed as parameters in the URL. These defences have been retired in 2018 and 2019. (If you have a really old Edge or Chrome browser, you could try this out if it helps here.) These defences might stop some classic reflected XSS, but it would probably not stop this DOM-based XSS: after all, the script here is not included in the HTML page returned by the server; instead, only when the JavaScript code executes will the malicious scripts are inserted inside the webpage via the name parameter.

The attacker's input may be passed back and forth between client and server and end up being HTML- or ULR-encoded, which may prevent input from being executed as script. In fact, for this page the name parameter in the URL is URL-encoded. Normally this would prevent it from being executed as script, as <script> URL-encodes to %3Cscript%3E. However, the JavaScript library function we use to retrieve the parameter values (the function get of the class URLSearchParams;check the source code of thi web page to see how that is done) is kind enough to automatically URL-decode data for us ;-)
If the JavaScript inside this webpage would (re-)URLencode the parameters before inserting them in the HTML then a simple DOM-based XSS is no longer possible. For instance, the URL-encoded name in the current URL displays as and this will not get executed as script by the browser.