XSS vs. XSSI: What is cross-site script inclusion?

What is the difference between cross-site scripting (XSS) and cross-site scripting inclusion (XSSI)? Are the defense methods any different?

Attacks that leverage XSS vulnerabilities have been around since the 1990s, and most major websites like Google, Yahoo and Facebook have all been affected by XSS vulnerabilities at some point. XSS-based attacks are different from most application-layer attacks (such as SQL injection) as they attack an application's users, not the application or server. These attacks work by injecting code -- usually a client-side script such as JavaScript -- into a Web application's output. Most websites have numerous injection points, such as search fields, cookies and forms. Although these malicious scripts can't directly affect server-side information, they can still compromise a site's security. By using Document Object Model manipulation to alter form values, change the look of the page or switch the form action to post the submitted data to the attacker's site, attacks can steal data, take control of a user's session, run malicious code or be used as part of a phishing scam.

 XSSI is a form of XSS that takes advantage of the fact that browsers don't prevent webpages from including resources like images and scripts, which are hosted on other domains and servers. Scripts, for example, may provide functionality that a developer needs to create a particular page -- many sites, including this one, include the JavaScript library jQuery hosted at

https://developers.google.com/speed/libraries/#jquery. This condition, however, can be exploited to read user data from one domain when that user is accessing another domain. For example, if Bank ABC's site has a script that reads a user's private account information, a hacker could include that script in their own malicious site (www.fraudulentbank.com) to pull information from Bank ABC's servers whenever a client of Bank ABC visits the hacker's site.

There are various measures developers need to implement to defend against XSSI attacks. One is to pass a unique, unpredictable authorization token to the user and require that it gets sent back as an additional HTTP parameter before the server responds to any requests. Scripts should only respond to POST requests. This stops an authentication token being exposed as a URL parameter in a GET request, and it also prevents a script from being loaded via a script tag. Browsers may reissue GET requests, which can result in an action getting executed more than once, whereas reissued POST requests require the user's consent.

When handling JSON responses, prefix the response with some non-executable prefix such as "\n" to make sure the script is not executable. A script running in the same domain can read the contents of the response and strip out the prefix, but scripts running in other domains can't. Also avoid using JSONP (JSON with padding) to load confidential data from a different domain as this opens the door to phishing sites collecting data. Sending the response header "X-Content-Type-Options: nosniff" will also help protect Internet Explorer and Google Chrome users from XSSI attacks.

To combat XSS attacks in general, specify the CHARSET in the HTTP Content-Type response header or in the http-equiv attribute in the meta tag in the HTML code so browsers won't interpret special character encodings from other character sets. For those developing sites in ASP.NET, the Microsoft Anti-Cross Site Scripting Library can help protect Web applications from cross-site scripting bugs.

There are plenty of open source vulnerability scanning tools that developers can use to test if their code is not open to XSS attacks such asVega, Wapiti, OWASP's Zed Attack Proxy and Skipfish. Sites should be scanned on a regular basis and certainly whenever changes to the underlying code are implemented or functionality that relies on third-party libraries is integrated into various pages.

searchsecurity