XSS & XSS Countermeasures

XSS

A Web application vulnerable to XSS allows a user without knowledge to send malicious data to them self through that application.
Attackers often perform XSS exploitation by making malicious URLs and tricking into clicking on them.
These links cause client side scripting languages like VBScript, JavaScript of the attackers choice to execute on the victim's browser.
XSS vulnerabilities are caused by a failure in the web application to properly validate user input.

The simplest description of cross-site scripting can be put as the attack that occurs when a user enters malicious data in a Web site. It can be as simple as posting a message that contains malicious code to a newsgroup. When another person views this message, the browser will interpret the code and execute it, often giving the attacker control of the system. Malicious scripts can also be executed automatically based on certain events, such as when a picture loads. CSS doesn't apply to any single vendor's products, instead, it can affect any software that runs on a web server.

CSS takes place as a result of the failure of the web based application to validate user supplied input, before returning it to the client system. "Cross-Site" refers to the security restrictions that the client browser usually places on data like cookies, dynamic content attributes associated with a web site. This causes the victim's browser to execute malicious code with the same permissions as the domain of the web application, an attacker can bypass the traditional document object model (DOM) security restrictions. The document object model is accessible application interface that allows client-side languages to dynamically access and modify the content, structure and style of a web page.

Cross-Site Scripting (CSS) attacks require the execution of Client-Side Languages (JavaScript, Java, VBScript, ActiveX, Flash) within a user's web environment. Cross Site Scripting can result in an attacker stealing cookies, hijacking sessions, changing of web application account settings and more. The most common web components that are vulnerable to CSS attacks include CGI scripts, search engines, interactive bulletin boards (Forums), and custom error pages with poorly written input validation routines. Also victim does need to click on a link to make the attack happen.

(Attack Example)

Example 1: The IMG tag

http://host/search/search.cgi?query=

Depending on the website setup, this generates html with the image from host2 and feeds it to the user when they click on this link. Depending on the original web page layout it may be possible to entice a user into thinking this is a valid part of the picture.

Example 2:

http://host/something.php?q=

If a user clicks on this link a JavaScript popup box displaying the site's domain name will appear. While this example isn't harmful, an attacker could create a fake form or, perhaps create something that grabs information from the user. The request above is easily questionable to a standard user but with hex, unicode, or %u windows encoding a user could be fooled into thinking this is a valid site link.

Example 3:

http://host/Inserthere

XSS Countermeasures

As a web application user, there are a few ways to protect yourselves from XSS attacks.
The first and the most effective solution is to disable all scripting language support in your browser and email reader.
Another recommendation is to use reasonable caution while clicking links in anonymous e-mails and dubious web pages.
Proxy servers can help filter out malicious scripting in HTML. If the application accepts only expected input, then the XSS can be significantly reduced. Web servers should set the character set, and then make sure that the data they insert is free from byte sequences that are special in the specified encoding. This can typically be done by settings in the application server or web server. The server should define the character set in each html page as below.

Web pages with unspecified character-encoding work mostly because most character sets assign the same characters to byte values below 128. Some 16-bit character-encoding schemes have additional multi-byte representations for special characters such as "<. These should be checked.

The above tells the browser what character set should be used to properly display the page. In addition, most servers must also be configured to tell the browser what character set to use when submitting form data back to the server and what character set the server application should use internally. The configuration of each server for character set control is different, but is very important in understanding the process of converting data that has more than one possible representation into a "standard" canonical representation of input data. Filtering special meta characters is also important. HTML defines certain characters as "special", if they have an effect on page formatting.

(HTML body)

"<" introduces a tag.

"&" introduces a character entity.

Some browsers try to correct poorly formatted HTML and treat ">" as if it were "<".

In attributes:

double quotes mark the end of the attribute value.

single quotes mark the end of the attribute value.

"&" introduces a character entity.

(URLs)

Space, tab, and new line denote the end of the URL.

"&" denotes a character entity or separates query string parameters.

Non-ASCII characters (that is, everything above 128 in the ISO-8859-1 encoding) are not allowed in URLs.

The "%" must be filtered from input anywhere parameters encoded with HTTP escape sequences are decoded by server-side code.

Ensuring correct encoding of dynamic output can prevent malicious scripts from being passed to the user. While this is no guarantee of prevention, it can help contain the problem in certain circumstances. The application can make an explicit decision to encode un-trusted data and leave trusted data untouched, thus preserving mark-up content.