Never Heard of XSS?
Web applications tackle major tasks every day — from online banking and stock trading to internal business functions that extend to customers. Unfortunately, that is a key motivation for hackers exploiting vulnerabilities in Web applications to hijack accounts, steal cookies and sessions, present false advertising and steal or manipulate whole databases.
An emerging class of worms, such as Yamanner or Samy, abuse a vulnerability in Web applications called "cross-site scripting," or XSS, that allows hackers to insert snippets of malicious code into a Web application, enabling them to control parts of the application when run with legitimate code. To foil this threat, you should add an input and output sanitation process to your code, regularly audit Web applications for vulnerabilities and put the right Web application firewall in place on your Web server.
In an XSS attack, hackers inject their own HTML or script snippets onto a page that is displayed by a Web application to the user. This code is then executed in the user's browser as a part of the Web page, and it can control the behavior of the Web page to perform malicious tasks. For instance, to perform a phishing attack on the login page of a bank, the attacker's code might modify the form action of the Web page to submit the data to a server controlled by the attacker instead of the bank. XSS vulnerabilities are caused when a Web application returns user-supplied data back to the user without sanitizing it first.
As a simple example, consider this URL, http://www.example.com/error.pl?errormsg="This is an error"
It prints the text specified by the 'errormsg' parameter (This is an error) on the Web page shown to the user.
Now, if the text is replaced with , the code snippet will be injected into the HTML of the Web page; http://www. example.com/error.pl?errormsg=<script>alert(document.cookie</script>).
When the Web page is displayed to the user, a java script alert containing the cookie of the Web page will pop up.
Another popular attack is known as an "SQL injection," in which hackers inject their own SQL code snippets into the SQL used by the Web application to perform operations on a database. This vulnerability is possible when user-supplied input (usually Web form data from a Web page) is used by the Web application to create a dynamic SQL query. If the Web application is vulnerable to such attacks, an attacker can simply enter an SQL query into a Web form, which is then executed by the database. As a result, the attacker can control the database and view and modify its contents.
Protecting Your Web Apps
It is possible to make your Web applications relatively secure by using the following methods assiduously:
Input and Output Sanitization. There is a golden rule for protecting a Web application against most attacks — validate and sanitize all user input and output without exception, based on a "Default Deny" policy. If this rule is followed diligently, it will eliminate not only the threat of XSS and SQL injection, but also most categories of Web application vulnerabilities.
User input means not only form fields and query strings, but all input that can be influenced by the user in any way, including HTTP headers and cookies, etc.
While designing any system, there are two policies a developer can use for user input — "Default Deny" and "Default Permit." Default Deny means that everything not explicitly permitted is forbidden, while Default Permit means the opposite: everything not explicitly forbidden is permitted. Security-wise, Default Deny is the superior policy to follow — nothing should be accepted as input or sent out as output by the system unless it is explicitly stipulated that it is allowed.
The application should have a central input and output validation module that strictly implements a Default Deny policy tailored to its specific needs. Some of the characters that can be used in attacks are > < ( ) [ ] ' " ; : - / \ NULL, etc. These characters should be sanitized or filtered whenever possible by an input validation. Input validation should happen before the user-supplied data is used by the application. It's also a good idea to filter out the term "script" and SQL keywords from user input, if possible.
| Deploy Web application firewall | 40% |
| Don’t know | 33% |
| Audit Web applications for vulnerabilities | 28% |
| Validate and sanitize user input and output | 22% |
| Use a default deny and permit policy on code | 22% |
| Total exceeds 100 percent because respondents could select more than one answer. | |
| Source: CDW survey of 316 BizTech readers | |
That takes care of the input. As an added measure of safety, all output that is sent to the user's browser must also be sanitized to ensure that hacker code snippets or other undesirable data do not slip through the input validation mechanisms and end up being sent to the user anyway. One way to do this is to "HTML escape" user-supplied data before displaying it back to the user. That means encoding characters that have special meaning in HTML (such as <, >, ", etc.) to what's known as their HTML entities; for instance, the character < is converted to <, > is represented as >, and " as ", etc.
Auditing. Auditing is indispensable for keeping systems secure. There are some very good free open source tools for auditing Web applications for vulnerabilities. The most important functions of these tools, such as the vulnerability scanning function, are automated and do not require a steep learning curve to start using them. They are useful for finding both XSS and SQL injection vulnerabilities before attackers find and exploit them.
Web Application Firewalls. Administrators should consider installing a Web Application Firewall (WAF), also called a Web application intrusion prevention system. They usually work in close cooperation with the Web server (sometimes as a plug-in) and protect Web applications running on the Web server from attacks.
A number of leading vendors produce products specifically aimed at protecting HTTP and HTTPS traffic. In evaluating WAF products, look for the following features and functions: encryption and authentication, filtering of outbound traffic, automated intervention and detection techniques (useful for protecting against new attacks), HTTP and SSL traffic monitoring, application logic, adaptable filters, SSL traffic, logging and reporting tools, XML support and remote management.
Deploying these kinds of applications in a production environment involves considerable effort, but they definitely increase the overall security of the system.
