Cross-site scripting (XSS) involves a website (such as a bank or e-commerce site) that collects user input and displays it verbatim back to the user without any filtering. An attacker can create Web content to access such a site, supply user input that includes a browser script and then trick the user into viewing the site with that content. For example, an attacker could send a victim an email with a legitimate URL that points to the site and provides it with a browser script as input. The attacker could also post a link in a news group or other third-party site, or post content on a site that allows third parties to upload information, such as a social networking site, Web mail provider, blogging site, etc. When a victim user goes to the site, the malicious content, including the script, goes back to the browser and runs there. The browser, unaware that the script is malicious, runs the program, and inadvertently allows the attacker's script to access any functionality of that site. It could steal cookies and send them to the attacker, or engage in transactions as the victim user. So, an e-commerce site that does not filter user input to remove potentially dangerous characters associated with browser scripts, is particularly vulnerable to XSS attacks.
How do you protect websites against cross-site scripting attacks? Web developers can implement filtering code for all user input to remove potentially noxious characters, or convert them to something that a browser will not run (for example, > and < can be converted to > and < respectively. CodeIgniter includes free PHP filtering code to prevent XSS and other kinds of attacks. To learn more about CodeIgniter, visit http://www.codeigniter.com.
Web users can protect against XSS attacks by disabling scripting in their browser, but this causes many websites to not function at all, or have severely limited use. Users can also configure a trusted zone in their browser to allow scripts only from sites they know are very unlikely to have XSS flaws. But, implementing such a solution is difficult. Also, avoid clicking on links in emails, newsgroup postings and third-party sites. Instead, only login to such sites directly, by typing their URL right in your browser or surfing there from a short cut. Although it's a good defensive principle, even that approach can be cumbersome. In the end, users typically depend on trusting that the websites they access will filter user input.
This was first published in July 2006