More JavaScript interacting with the DOM

This webpage contains JavaScript that uses the DOM API to make changes to the webpage. Look at the page source in a separate window to see the JavaScript code while you play around with it.

The button below uses the DOM API method document.write() to rewrite the entire content of the current web page

The method document.write() is a very drastic way to change a web page. A more controlled way to change a webpage is using the innerHTML field of an elemement of the webpage to rewrite just that element. The button below, demonstrates that behaviour. It only changes one paragraph of the wewpage, namely the paragraph with the tag demo.

A small paragraph of text, with the tag demo.

FOR YOU TO DO: Look at the JavaScript in the HTML source of this page to see how that is done.


Inspecting the URL with JavaScript

Below this webpage includes JavaScript that uses the DOM API provided by the browser to extract data from URL and write it back inside the web page. It uses:

You can test that this works by adding parameters and a fragment to the URL; for an example, click here.

The URL of this page is:

Below we use JavaScript to extract data from the URL:

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

FOR YOU TO DO: Edit the URL in the address bar of your browser to add HTML markup to the name and sid parameters and the fragment. You should be able to see that 1) your browser URL-encodes some of this data that you type the browser URL bar and that 2) some of the DOM API methods (but not all) are kind enough to then URL-decode this. You should be able to sneak in some HTML into this webpage via the URL and also do XSS.

The behaviour of the DOM API is very subtle -- not to say horribly complicated: some DOM API methods will render arguments as HTML but not execute any JavaScript included in these arguments, so that they are safe to use, while others do allow the injection of JavaScript. This webpage uses the dangerous method Document.write() and the dangerous property innerHTML which can trigger JavaScript exection. The documentation of the DOM API, included as links in the text above, will warn about this.

Client-side security risks of URL parameters

Client-side processing 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, when processed in the browser, results in XSS. An example is shown in XSS_via_the_DOM, but you should be able to inject JavaScript into this webpage as well.

Of course, malicious parameters in the URL can also be used for injection attacks, such as path traversal and SQL injection, but note that these problems occur server-side, and not client-side like XSS does.

Server-side, a web application can -- and probably should -- check for malicious parameters and sanatise or remove them; it could also reject the entire HTTP request if there malicious parameters in the URL. One exception here is the fragment part of a URL, i.e. the optional part of the URL after the # character. The fragment in the URL is not sent to the server; it is only processed locally in the client, where it is used to specify an offset, a so-called anchor, within a webpage. Fortunately, in that case it will not be executed as JavaScript, so a malicious fragment containing JavaScript can't be used to executed as JavaScript by the browser. (JavaScript in a webpage can inspect and use the fragment in any way it wants, in which case a malicious fragment could lead to XSS, but it very unusual to do this).