In 2007, Cross Site Scripting (XSS) attacks made up roughly 80% of all documented security vulnerabilities. In three hours, the Eos web team discovered 27 Australian corporate websites that are potentially vulnerable to this type of web-based attack.
For obvious reasons we can’t provide a list of the names and URL’s of the websites we discovered with this flaw, so in the article below we’ve opted to provide more info on XSS attacks and to illustrate how to prevent them.
Hopefully you can check if this problem is affecting your website and take steps to remedy any issues.
So what is an XSS attack? To quote Wikipedia:
"Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which allow code injection by malicious web users into the web pages viewed by other users. Examples of such code include HTML code and client-side scripts."
An XSS attack is particularly relevant to Australian businesses due to the number of recorded vulnerabilities and the ease in which one can actually craft this type of attack.
The Open Web Application Security Project (OWASP) describes three types of XSS attacks:
1. Reflected Attacks are where content supplied by the user to the web server is returned unfiltered like an ECHO request.
2. Document Object Model (DOM) attacks are an advanced version of the reflected attack using a scripting language (usually JavaScript) to manipulate the page, send unsolicited data to another domain without the user’s knowledge.
3. Stored Attacks are where the malicious data of either type one or two is stored in a back-end system and is delivered potentially to multiple users. This is especially relevant for blogs and Content Management Systems (CMS).
To illustrate the concept, below is an example.
Many web applications use data appended to a URL in a GET request to pass data between pages. This technique can be used to maintain a state much like session cookies.
For example in the URL http://www.domain.com?Name=Terrence we are passing a name value pair which is essentially “Name equals Terrence” back to the server. When this is sent to the server it parses the request and extracts the Terrence portion from the example and inserts text into the returned webpage so we see something on the page like Hello Terrence.
If the application or server does not check the value of the Name parameter being passed in and blindly passes it back to the user as part of the rendered content you have the making of an XSS attack.
As a malicious user, you could craft a URL to that same page, such as:
http://www.domain.com?Name=MaliciousCode
You could then send this link out in an email campaign. The malicious content could include any code that the browser supports such as HTML, CSS, JavaScript or VBScript.
When the user receives the email and clicks on the link (under the assumption they are clicking a link to a trusted site) the malicious code is embedded in the returned page and executes under the URL of the website it was sent from. Using JavaScript, one could rewrite the whole page and entice a user to provide sensitive information or rewrite the webpage to present false information to the user as if it were an official message from a trusted website. Anyone with HTML and JavaScript knowledge can create this type of attack.
There are a number of ways to protect your website against this type of attack. Some quick tips:
1. Validate all data coming in from un-trusted sources and encode all output data
2. Any data coming in through form fields, query strings or even cookies should be filtered to allow only valid characters to be passed in.
3. Any untrusted content sent to the user should be encoded with a character set consistent with the web page character set (which should be explicit).
There are many ways to do this - for example the formula:
@URLEncode( encodingFormat ; token ) can be used to encode data returned to website users.
4. On the client side using JavaScript regular expressions are a powerful way of filtering content before it is sent to the server. At this point it should be noted that JavaScript alone should never be relied upon to validate incoming data as it is relatively easy to disable.
This article only scrapes the surface of this vulnerability and you can probably see the potential for damage if this type of exploit is left unchecked on your website.
If you would like more information on XSS attacks, or would like to arrange a website security review and consultation, please Contact Us.