DOM type XSS (Cross site scripting)

With a vulnerability to an XSS attack an attacker can either:

1. Exploit a website server to process certain user side (i.e. client side) input as if it were its own server-side command code. This type of attack is categorized as either "Reflected XSS attack" or "Stored XSS attack". The attacker types in unusual input into legitimate fields (or the URL address field) on the page. By doing so he manages to insert his own code (Java script commands) as part of the server's site code. This requiresz specially formatted text input in order to manipulate the server. If successful, the server is manipulated into processing the inputted text as instructions, instead of what it was originally meant to be interpreted as.
2. Exploit another of the domain visitors' BROWSER (i.e. Firefox, Google Chrome, etc.) to process the attacker's input as if it were Java-script commands, instructing the victim's browser to perform certain actions. This is known as DOM type XSS.

The malicious script DOES NOT travel all the way to the server, but rather stops at the client side. Because of this, it has no effect on the server-side.

Short description of the DOM XSS vulnerability and its dangers:

This vulnerability means an attacker can exploit another of the domain visitors' BROWSERS (i.e. Firefox, Google Chrome, etc.) using the domain's webpage as a vector to enable the attack.

The attacker simply navigates to the domain webpage, loads the client side of the domain, but then manipulates his downloaded copy. He then sends a link from this manipulated copy to the victim. When the victim clicks on said link he is indeed transferred to the original website, but also at the same time, certain malicious instructions interact with his browser program. While it may seem like the only one being victimized is the targeted visitor/surfer of the site, it must be stressed that by exploiting this "third party" browser an attacker can then steal the domain's cookies given to the victim's browser (also, he is able to steal the session storage).

This is potentially very damaging to the website, since the hacker can use this stolen information to gain unauthorized access to webpages in the domain.

Dangers: cookie theft, unauthorized access to the domains' webpages, usage of unprotected webpages as tools to damage their visitors’ browsers.

Severity level: high.

Short example of a found DOM XSS vulnerability and its exploitation:

By adding '%23%3Cscript%3Ealert(1)%3C/script%3E' to the domain's URL address, an attacker may be able to inject his own java-script code to interact with and instruct the victim's browser (in this case the command will simply produce an alert, but more damaging scripts can be injected).

The resultant URL address (http://www.shekerkolshehuwhatever.com/form.php#%3Cscript%3Ealert(1)%3C/script%3E) is then copied and pasted as a link to be sent to the victim. The victim is persuaded under some false pretense to click on the malicious link, and by doing so enables the attacker to exploit his browser. (note: the URL is an HTML encoded URL address of the address: http://www.shekerkolshehuwhateve.com/form.php#. The encoding process was performed by the famous Burp-suite tool.)

While the Domain's server is not the explicit victim, it is used as a vector, as the attacker manipulates its webpages to formulate his own URL address and to send its link to a victim. Thus, the victim may be damaged by trying to surf and visit the tested domain, which is not protected against such attacks.

How to fix: This problem’s root is a vulnerable java-script function, which is used in one of the page's elements. This function is referred to as "the sink".

This "sink" enables the attack in combination with an input source that impacts it.

The second condition is that the source of the sink enables textual input by the client-side (sites user). For example, the source could be the URL address field (which, as we know, it is indeed writable, and thus, under the control of the attacker).

One way of fixing the problem is to add encoding to the URL input. This will limit the attacker's control over the URL field because he will not be able to input certain characters without them being encoded.

For example, if we instruct the site to encode text typed into the URL as input by the user, it would render the attack useless. This is because the data will be sent to the server, and the server-side filters will disable the attack.

The sink in this example case, would be a function which points to the page element of the URL field.

The second way of fixing this vulnerability is by altering the bad java-script function to a more secure one.

This could be achieved by changing the reference to the source element.

If we reference it as ".InnerText" instead of ".innerHTML", the referenced input will be regarded as strictly textual input, and by no means a java-script command.