Think your web applications are safe from cross site scripting? Maybe, maybe not. Why take a chance?

I recently put together some notes for a presentation on cross site scripting, or XSS for short. I have decided to share some of the information, because I believe keeping a few thoughts in mind as we develop and test will go a long way when it comes to preventing attacks.

Cross Site Scripting – What is it?

Cross site scripting occurs when a web application gathers malicious data entered from a user, with or without negative intent. XSS can be achieved by exploiting locations in source code where users are able to input data, and the proper preventative measures have not been implemented to format and validate the inputted data. In other situations, session cookies and other sensitive data can be accessed by injecting malicious data and ultimately hijacking or impersonating a user’s account.

There are three main types of XSS according to Wikipedia, so I won’t bother rephrasing. Visit http://en.wikipedia.org/wiki/Cross-site_scripting for more information.

The most common technologies and languages used for XSS are JavaScript, VBScript, ActiveX, HTML, or Flash’s ActionScript. Not only do we need to protect our server code, but we need to think about our client code as well.

Prevention of Cross Site Scripting

The vast of majority of XSS attacks can be prevented by identifying the user input locations within the web application and ensuring the source code handling these has proper measures in place. From a developer’s perspective, this means ensuring all data inputted from a user is properly encoded to remove HTML and script markup to be replaced with text that all browsers can process.

A simple example in C# is to use the HttpServerUtility.HtmlEncode method to convert all HTML markup characters into their text equivalent. For example, if a user were to supply the input for a textbox with the following, “This is my <b>bolded text</b>.” The end result of the HtmlEncode method would result in the following, “This is my lt;bolded textgt;.” This is important because it removes HTML markup, which could be malicious. For example, “This is my text. <script>alert(‘This is an attack’);</script>.” This example is passing a JavaScript alert to open a modal popup on the screen to display to the user.

In addition to HTML inputted data encoded on the server, encoding data on the client can be equally important. JavaScript HTML elements can have two attributes, InnerHTML and InnerText. InnerText will render text, not HTML, so it is the safe option. InnerHTML can be used to inject an XSS attack because it can render user inputted HTML, including script. Ensure InnerHTML has the necessary string formatting to protect against this vulnerability.

Cookies are another vulnerability to XSS attacks. If any part of the website issues cookies and an XSS access point is discovered, it is now possible to steal cookies and private information from the application’s users. If the cookie can be accessed, so can the information with it. Users can be impersonated, and site credibility will be lost.

Encrypted web sites (SSL, HTTPS) are at risk just like their public counterparts. SSL sites appear to be protected, but it is possible to execute the same XSS attacks, they just happen over an encrypted connection.

To protect our web applications, we need to be aware of the XSS vulnerabilities common to attackers and place defensive measures to ensure user confidentiality and confidence. Without becoming an expert on XSS and security, it is possible to develop safe, reliable applications by understanding XSS and the vulnerabilities exposed by our applications.

What to Look for in Source Code

Execute a simple search in source code looking for certain keywords is a good starting point. Many of the XSS bugs I have seen reported could have been prevented with the simple measures. Ensure HTML input is properly encoded on the server using HtmlEncode. Ensure HTML input is properly formatted on the client using string.Format and InnerText.

In source code and wherever, look for the following vulnerabilities.

• InnerHTML
• InnerText is not supported by all browsers but the two can be found together. Look for where the strings are originating and if they are properly formatted/encoded.
• SetInnerText()
• JavaScript’s Eval()
• Don’t be Eval - http://24ways.org/2005/dont-be-eval
• Assigning of strings to page titles, control titles, ect.
• Sometimes we take request object data and immediately process it and render it on the client.
• Check the URL parameters passed in.
• The Request object
• Request.Params
• Request.Forms
• Request.QueryString
• Using HtmlTextWriter or any variation
• RenderBeginTag()
• AddAttribute()
• RenderEndTag()
• HtmlWriter.Write()
• Cookies
• Where are we using them and how are we handling them

Searching for these keywords within source will be a decent starting point for discovering XSS vulnerabilities

Microsoft Anti-Cross Site Scripting Library V3.0 Beta

Feel free to use a Microsoft API designed for XSS prevention within your code.

http://www.microsoft.com/downloads/details.aspx?FamilyId=051ee83c-5ccf-48ed-8463-02f56a6bfc09&displaylang=en

Closing Notes – because this topic can go on forever

There are tools to help assess if your site is vulnerable. Search for them online. Whether or not you think you need third party APIs to help you write defensive code is entirely up to you. You can always write the code yourself.

Cross-site scripting (XSS) can be damaging to a company’s credibility and can cause myriad undesirable effects for individual users. XSS is preventable. Familiarizing oneself with the smells of XSS is a valuable tool to posses as a developer and a tester. At a minimum, educate your developers and testers on the target hot-spots mentioned within this post.

References and Resources

http://en.wikipedia.org/wiki/Cross-site_scripting

http://www.cgisecurity.com/xss-faq.html

http://ha.ckers.org/xss.html

http://www.owasp.org/index.php/Cross_site_scripting