What about the designers and maintainers of Web sites? you can reduce the problem with a variety of ways highlighted in this section, including a checklist at the end for Web developers.
First, validate the input. The following script accepts a parameter and reflects the same on the display.
A vulnerable script that accepts and reflects a parameter
#!/usr/bin/perl use CGI;
my $var1 = CGI->new(); my $parameter = $cgi->param('text');
print $var1->header(); print "parameter";
This piece of code is vulnerable to XSS attacks because no check is made to validate the input. The solution is to validate the input and HTML and escape the data before displaying the same. HTML escaping data means that non-alphanumeric characters are internally represented differently; for instance, with the lesser than (<) and greater than (>) signs represented as a string of characters (< and >).
Add input validation in this manner:
$parameter = ~ s/[^A-Za-z0-9 ]*/ /g;
This validation allows only alphanumeric and space characters and filters the rest. You can further strengthen validations by adding:
This snippet actually encodes HTML characters as HTML entity references. Characters like the less than sign< are encoded as "<" to help filter out such attacks. However, this is the not the end of the solution -- attacks can come in other forms.
You can add input validation to the script by inserting the following line of code before any output. This code eliminates any input other than letters, numbers, and spaces.
$text =~ s/[^A-Za-z0-9 ]*/ /g;
This script is vulnerable to cross-site scrypting attacks because it blindly prints out submitted form data. To get rid of this vulnerability, you can either perform input validation or ensure that user-submitted data is always HTML-escaped before displaying it.
With that in mind, TaintRequest automates the process of HTML escaping data. It always validates and HTML escapes the content before displaying or printing the data. (Perl has a feature like Taint mode built into it that can be used for such security checks.) This method ensures that any external data that flows into the program is not used directly for handling files and directories or for executing processes. Apache::TaintRequest is a very powerful check for preventing such attacks and making the application less vulnerable to XSS hazards.
To activate this feature, insert the following into the httpd.conf file.
Do the following to ensure that the scrypt uses
use Apache::TaintRequest; my $var1 = Apache::TaintRequest->new (Apache->request); my $parameter = $var1->param('parameter'); $r->content_type("text/html"); $r->send_http_header; $parameter =~ s/[^A-Za-z0-9 ]//; $r->print($parameter);
This piece of code takes up tainted data from the user, ensuring protection as it checks that the characters to be printed are only alphanumeric characters and spaces.
The following is a checklist of ways for webmasters and developers to prevent XSS attacks:
Guarantee that the pages in the Web site return user inputs only after validating them for any malicious code. Filter Meta characters in the input while validating it. (This can be a major checkpoint to eliminate XSS attacks. Although it doesn't eliminate all XSS problems, it can alert Web maintainers to inadequacies in a site's security.) Do not completely trust Web sites that use HTTPS (Secure Sockets Layer) when it comes to XSS; HTTPS ensures secure connections, but processing of the data entered by the user is internal to the application. If the application has XSS holes, the attacker may send a malicious script that can still be executed by the application and lead to XSS intrusions. Convert all non-alphanumeric characters to HTML character entities before displaying the user input in search engines and forums. Use testing tools extensively during the design phase to eliminate such XSS holes in the application before it goes into use. (A best practices guide that stresses this is the philosophy of Extreme Programming.) Develop some standard or signing scripts with private and public keys that actually check to ascertain that the script introduced is really authenticated. (To implement things on such a large scale, the Internet rules have to be standardized to derive a common methodology with input from major players such as W3C.)
A pound of prevention...
Cross-site scripting attacks pose an immense risk. Attacks can result in problems ranging from identity theft for one user to incursions that involve major financial and security issues for millions of consumers and businesses. Such remedies as input validation and HTML escaping are a start, but they must be applied at all application points that accept data. An application with a single overlooked form field is just as insecure as one that does no checking whatsoever.
This article doesn't cover the complete solution to XSS-style attacks -- I've only discussed the individual approach that users and Web developers can take. Another component to the prevention of these intrusions must come at a global, industry level -- more research and coordination of international standards.