Cross-site scripting is a serious security issue facing Web developers. This exploit allows malicious Web site operators to abuse the trust relationships Web users have with unrelated third-party sites and execute

    Requires Free Membership to View

arbitrary scripting code on an end user's system.

The easiest way to describe cross-site scripting is with an example. Suppose that Mal, the operator of www.malicious.com decides to take advantage of this vulnerability to affect users from Acme Widgets. Mal knows that Acme operates an intranet site that hosts a feedback form at www.feedback.acme/form.htm. This form processes user feedback and displays a confirmation page thanking the user for their submission and displaying the data that was entered on the page. Mal also knows that users within Acme have the www.feedback.acme site listed as a trusted site, while his site www.malicious.com is an untrusted site.

To implement the attack, Mal places a hyperlink on his site labeled "Free Beer, Click Here!" (or whatever) and codes it to submit data to the Web page that processes input from www.feedback.acme/form.htm. In the feedback field, he enters the message "Thanks for everything."

More on XSS

Cross-site scripting: Intro to XSS 

Cross-site tracing explained 

Cross-site scripting explained: How to prevent XXS attacks

When the user clicks the "Free Beer, Click Here!" link, he or she unintentionally submits the form to the trusted site, resulting in their browser displaying a message thanking them for their input. However, when the browser encounters the portion of the page between the tags, it executes it as Web scripting code.

Now, you may ask what benefit lies in redirecting users from Mal's site to Acme's site. This lies in the trust relationship. True, Mal could simply place the script on his own site and bypass the cross-site part of the scenario. However, in this case, Mal's code would be handled by the browser's rules regarding untrusted sites. By using cross-site scripting, he effectively hijacks the trust relationship between Acme users and Acme intranet sites and forces the execution of his code according to the browser's rules for trusted sites.

Unfortunately, there is no simple fix for the cross-site scripting vulnerability. Web developers must be careful to filter out the tags and any other sensitive HTML elements from processed data before redisplaying it in the user's browser. As with many Web security issues, vigilant programming by security-conscious developers is the best solution.

About the Author
Mike Chapple, CISSP is an IT Security Professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force.

This tip originally appeared on SearchSecurity.com

This was first published in December 2005

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.