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
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."
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