What to Know About XSS

Irvine, CA – July 16, 2008 – Tevora Security Consultant, Brian Monthie, contributed the following article to NETWORKWORLD, a premier provider of information, intelligence and insight for Network and IT Executives.  This article can also be viewed by clicking here. 

In 2005, a MySpace user named Samy discovered a unique way to expand his buddy list. Within 24 hours, the number of friends on his page grew from 73 to more than 1 million. He achieved this instant popularity by creating the first self-propagating cross-site scripting (XSS) worm and by exploiting the lax security in many Web browsers.

Most Web sites today use MySpace-like dynamic content features to connect communities of users, enhance users’ site experiences and extract detailed user information. However, the applications that generate dynamic content are vulnerable to infiltration by XSS, which can be employed for far more nefarious aims than instant popularity. A better understanding of this threat is critical to detection and prevention.

XSS is an attack on the client-side or front-end of a vulnerable Web site.  The malicious code is typically JavaScript that is encapsulated in HTML or IFRAME tags which aid the disguise of the payload and help avoid any input validity checks.  The code is accepted by a vulnerable Web site because the Web application believes it is valid user input.  In reality, the XSS code will ultimately attempt to steal confidential visitor information which will be used later to impersonate the victim on the visited site.

XSS attacks come in a variety of forms. The most popular on the Web today are stored, reflected or based on the JavaScript document object model.

•  Stored or Persistent XSS attacks are the easiest to carry out and most expansive. Similar to an e-mail worm, Stored XSS gets created once and is then injected into a vulnerable site where it is stored in files, databases or forums to be executed by any unsuspecting visitor. When visitors log into a Web page that has been infected their authentication information is duplicated and routed to the attacker’s credential collection server.  After that the attacker can use the collected information on that Web site and possibly on other sites where the victim has used the same credentials.

•  Reflected or Non-Persistent XSS attacks are similar to phishing scams. Reflected XSS uses the skeleton of a trusted Web site — the same look, feel and information passes back and forth from the visitor to the site — only the attacker has created a tunnel to a different site to capture the traffic.

•  Instead of targeting weaknesses in Web sites like Stored XSS or in people like Reflected XSS, DOM-based XSS attacks — which are still in their infancy — target the way JavaScript handles its object structure.  JavaScript uses DOM, a hierarchal, object-oriented model, to map the elements within a Web page.  DOM-based XSS attacks exploit the trust relationships in the DOM model.  Once elements are parsed by DOM, they can be trusted by other domains, and this is especially true with newer, more JavaScript-driven Web sites.  If malicious XSS code can be injected into the DOM, it can be used on more than one site since DOM can be referenced by the Web browser across different domains.

An XSS attack is successful if an attacker can get site visitors to divulge login credentials and hijack their accounts, steal or manipulate a victim’s cookies, read a history of sites the victim visited, or even grab the local IP address from the victim’s computer.  The attacker develops a profile on visitors much like a trusted Web site would, only for malicious purposes.

Many Web sites remain unprotected against XSS, which means these sites have either unwisely chosen to ignore the risks or, like many users on the Web, are simply unaware of XSS’ destructive capabilities.

The problem with preventing XSS is it doesn’t fit a certain signature or profile, it isn’t limited to a particular port or protocol, and it isn’t vendor specific.  Furthermore, XSS, when it is encoded with HEX, DWord, or ASCII, can look like legitimate JavaScript running on the Web site.

Internet Explorer, Mozilla and Safari all have XSS-associated vulnerabilities.  Mozilla hopes to eliminate XSS vulnerabilities in version 3, while IE6.1 SP1 has included the HTTP-Only cookies variable to reduce XSS impact.  But XSS is becoming a cat and mouse game with attack vectors and payloads outpacing the browser patches.

With the growing popularity of customer-driven content sites such as Youtube, Myspace and Ebay, XSS has gained momentum.  In fact, searching for XSS on Youtube.com will return numerous tutorials explaining just how easily and frequently this attack can be executed.

How can XSS be alleviated?

Even though it is proving difficult for vendors to eliminate XSS risk entirely, these steps can help Web site operators reduce the risks for visitors:

1.  Reduce the Impact.  Decide which Web applications must be safeguarded to ensure business continuity and eliminate other programs that are no longer used.  It is very common for companies to have unused applications on their sites, and Google still indexes those applications so they represent unwarranted risks.

2.  Sanitize the Input.  Start with the end in mind and work back.  Determine what the customer or visitor will experience and what areas (such as HTML input fields) are susceptible to an XSS attack.  A JavaScript scanner would help automate the task here.

3.  Work back to the Source. Apply input sanitation and validation checks to site development methodologies.  OWASP, an application security community, runs a comprehensive knowledge repository on cross-site scripting rich with information on how to alleviate XSS.  One such suggestion from the community is to define alpha and numeric characters that are acceptable in the application input data and filter out everything else that doesn’t fit the schema.  Resolving to write cleaner code will not only help simplify development efforts, but will also ensure better secured Web sites.

4.  Be Proactive. Take a more active approach to mitigating XSS risk.  Although relatively cutting-edge, web application firewalls (WAFs) are designed to specifically handle layer 7 requests and can be effective countermeasures when used in conjunction with other defensive measures for stopping XSS attacks.  A company that makes itself accountable for its visitors’ experience can reaffirm its trustworthiness or even gain new trust in the process.

Each company and its associated Web sites will have a different approach to alleviating XSS vulnerabilities because each company values customer information differently.  A company interested in generating increased traffic, maintaining its ties with its current customers, and differentiating its security domain from its competitors would do well to consider these XSS mitigation strategies.

Brian Monthie is a security consultant with Tevora Business Solutions, an enterprise solutions provider focused on security and compliance.  For more information, please visit www.tevora.com, or contact Brian at bmonthie@tevora.com.
About Tevora Business Solutions Tevora Business Solutions Inc. is an enterprise solutions provider focused on security and compliance.  With a distinctive combination of proven products and services, Tevora aids enterprises in protecting their most important assets from external and internal threats.  Tevora’s practice is based on the need for clarity, objectivity and expertise in the design, implementation and validation of network security solutions.  Headquartered in Irvine, CA, Tevora’s areas of practice include risk management, compliance and business continuity.

For more information, visit: www.tevora.com

Media Contact:
Nazy Fouladirad
of Tevora Business Solutions
+1-949-250-3290