More JavaScript interacting with the DOM

Rewriting an HTML page in the browser using JavaScript

The button below uses the function document.write to rewrite the entire content of the current web page loaded in your browser.

A nicer demo of rewriting an HTML page in the browser using JavaScript

A bit nicer is the button below, which only rewrites part of the content of your webpage, namely the paragraph with the tag demo just above

A small paragraph of text, with the tag demo.

Inspecting the URL with JavaScript

Below we use JavaScript to extract the URL from the DOM, and write it back inside the web page. You can test that this works by adding superfluous parameters to the URL, e.g. ?name=john, or adding a fragment at the end of the URL, e.g. #demo, which should then be displayed below when you load this new URL. For example, click here.

The URL of this page is:

With JavaScript we can now also extract parameters from the URL. The JavaScript functions we use for this (from the URLSearchParams interface) might not work in all browsers, but most (all?) modern browsers will: see the list of browsers that support it.

    The parameter name has the value:
    The parameter uid has the value:
    The fragment part of the URL is:

FOR YOU TO TRY: Edit the URL in the address bar of your browser to add uid and name parameters or a so-called fragment part, i.e. make it a URL of the form http://www.cs.ru.nl/~erikpoll/websec/demo/demo_DOM2.html?name=john&uid=1234#someFragment.

Security risks of URL parameters

Client-side processing (i.e. processing by JavaScript inside a web page) of parameters in the URL as we do above is not without security risks. An attacker could try to create a malicious URL with a 'poisoned' parameter in the URL that ends up in a context where it is interpreted as JavaScript, which then results in (DOM-based) XSS. When we get around to XSS we will add a demo page http://www.cs.ru.nl/~erikpoll/websec/demo/xss_via_DOM.html illustrating that. You may be able to trigger XSS on this webpage too. Poisoned parameters in URL can also end up in other places where they trigger unwanted behaviour, for instance SQL injection.

Parameters vs fragment in a URL

Parameters in the URL are sent to the server but the fragment part of a URL, i.e. the optional part of the URL after the # character, is not sent to the server. The fragment is only processed locally in the client. The traditional use of the fragment is to specify an offset (a so-called anchor) within a web page, but JavaScript in a webpage could use it for any other purpose. Again, this is dangerous (and unusual) as a URL with a malicious fragment string could then trigger unwanted behaviour. And whereas a web server can (and should!) check parameters in a URL if there is the possibility that they can be abused (and then sanatise - i.e. validate and/or encode - them to make them harmless, there is no way for the server to inspect anything that is inside the fragment part of the URL.