XSS

Tags: exploit networking

Is a security attack targeting web applications using code injection to [see page 9, execute] arbitrary code on the client-side (web browser). It can be used for stealing cookies, session-tokens and other sensitive information.

See [see page 7, consequences]. See [see page 8, OS vs. Browser] analogies and primitives.

XSS generally works by delivering the malicious script to the victim in some form and having them execute it on load.

Many web-applications have fields which the user can submit and the site can then render back on load, such as the users name. An attacker can [see page 11, [inject](com3501-w10-XSS-PWPT)] some script in the middle of a submitted field and then when the site renders it back anyone visiting the site will have the script executed on their browser. This script could [see page 13, [redirect](com3501-w10-XSS-PWPT)] to an attacker controlled domain including the current session cookies in the sent request, where the attacker can control the session interaction between the client and the server.

Delivery Mechanisms

Reflected XSS

A XSS delivery mechanism where the malicious script see page 15, bounces of another website to the victims browser. The script is generally passed in the clients request query meaning the client is compromised from the moment they follow a link shared by the client.

This works by:

Having the Attacker craft a malicious URL containing the vulnerable JavaScript.
When the victim opens the link the URL will render the script and subsequently compromise the client.

This could be used with search engines that don't properly sanitise the input query. The search engine will normally render the search query into the page so the user can modify it. If the query contains a script tag and the server renders as is then the script will evaluate and the query will appear as an empty string (or some other suffix string the attacker leaves in the attack URL).

Stored XSS

A XSS delivery mechanism where the malicious script is [see page 21, stored] on a remote server directly, and any users that access it automatically have the script run. Consider a social network where users can post arbitrary text, if one person posts the script then anyone who views their post will run the script and be compromised.

This approach has the added advantage that the victim will generally be logged into the site.

This is known as Persistant XSS because the attack is persistent across all the users that access the site in question, it isn't dependent on the attacker actively sharing a specific attack link.

Local XSS

A XSS delivery mechanism that bypasses the server entirely and has the client pass the URL including the malicious JavaScript (contained in the fragment section of the URL) from the clients browser to the clients OS-level viewer which will evaluate the JavaScript.

Countermeasures

The techniques described below can be [see page 31, prevented] at the Browser or server level by looking at outgoing or incoming traffic. XSS works by allowing dangerous constructs such as scripts or unsafe links to be rendered directly. This can be prevented by having the:

server [see page 32, quote/escape] certain tags or elements when saving or retrieving it.
browser:
- Block all scripts in URLs in outgoing HTTP traffic.
- Stripping any incoming scripts if they match any scripts found in the outgoing request.
Both these approaches were [see page 32, discontinued] because they have too many false positives.

Input Validation

Try to [see page 26, spot] and stop the malicious input that causes XSS.

Black Listing

[see page 28, Replaces] dangerous character in input strings with underscores or other harmless characters. Essentially check if the input is valid and if not try to make it valid.

This requires the program to identify all dangerous characters and strings in the input and replace them with something that prevents the danger they present. This requires knowledge of the specific libraries or procedures that the malicious code may be passed to.

White Listing

Defines a list of acceptable characters/strings and removes characters that are unacceptable. Essentially check if the input is valid and if not reject it.

Note: rejecting suspicious input is [see page 30, more secure] than trying to sanitise it.

The list of valid input is typically predictable, well defined and of a manageable size.

Web Application Firewall

Can be added as a [see page 34, layer] of defence against XSS between the browser and the web-server. It can be taught what normal input should look like and stops unusual ones... such as if a user-id is normally a number but is passed as a script.