Reports of vulnerabilities in web applications have risen sharply. Exploits are easy to develop and targets are easy to find. It is therefore important that we adapt to these threats, when programming and also when we use these applications.
Web applications are commonly used from a web browser and they cover a range of activities, such as e-banking, webmail, online shopping, community websites, blogs, vlogs, network monitoring and bulletin boards.
In recent years the development of such applications has been considerable, and today rich internet applications offer complex, real-time interactions with users. For instance, web operating systems such as eyeOS offer many functionalities that were previously available only with traditional operating systems.
While web applications have become ubiquitous, they also present new security risks. It is important to identify and understand these risks when developing, hosting or simply using these applications.
Security risks
There are two main reasons that web applications are vulnerable to attack.
First, it is generally difficult for the service manager to keep up to date with security patches. This is a common issue for services in general, but it may be particularly challenging for web applications. This could be improved by better design and packaging but it is often impossible to upgrade web applications automatically. This requires the service managers to actively monitor announcements by the application vendors. It may also be necessary to customize the application to meet the community's needs, and this may result in additional delays to an upgrade.
Second, web applications are often easy targets for attackers. As a relatively recent development, they use non-mature code compared to traditional network services. Unfortunately exploits – malicious code that exploits software vulnerabilities –are generally easy to prepare, remotely executable, cross-platform, and require no compilation. This helps attackers to design effective and scalable automated attacks. Vulnerable installations can be found quickly, easily and silently by using search engines to detect known vulnerable patterns, generally filenames, of specific web applications.
Not only critical services are at risk
It is important to understand the threats against which web applications need to be protected. Several years ago attackers were mostly attracted by challenge or fame, but since then attacks have become more professional and many attackers are now motivated simply by money (e.g. phishing, spam, extortion, distributed denial of service attacks (DDoS), and click fraud). Some malware kits have also become professional: user friendly, modular (it is possible to buy extra components), and some even include one year of support. For more information, an interesting article about the Storm Worm is available at www.schneier.com/blog/archives/
2007/10/the_storm_worm.html.
A result of this professionalization is that attackers need bandwidth and platforms to operate from. To obtain and maintain a sufficient amount of compromised resources, attackers usually choose the easier target. No matter how insignificant a particular service may be, it is worth something for an attacker: an unmaintained photo album may be worth as much as a critical production service.
For instance, once a web application has been successfully compromised the attacker may gain the ability to:
• cause damage to the reputation of the organization running the service;
• execute code remotely with the privileges of the user running the web server – this is sufficient to run botnets and spam engines, and enables the attacker to try to spread the attack further on the system or against third-party services;
• access all the information hosted on the web server;
• change the content of the website (defacement); and
• delete files or damage web services provided by the host (denial of service).
Shift in the vulnerability trends
There are different types of web application flaws, but the most common are caused by a lack of user input validation. Data coming from the client must be filtered to ensure that no malicious content is passed to the server. If this is not performed correctly, the resulting vulnerabilities include:
• Cross-site scripting (XSS). If a parameter is not sanitized correctly an attacker may be able to control the content of the vulnerable page. To perform the attack the victim is often tricked into clicking on a malicious link, but this is not always necessary for the attack to be successful.
• SQL injection. Some parametersretrieved from the user's web browser may be used to perform database queries. If a parameter passed from the user to the database is not correctly filtered, an attacker may attempt to execute arbitrary SQL commands and/or to gain privileges on the web application.
• Remote file inclusion (RFI). By exploiting insecure calls to local files, such as templates, an attacker may attempt to upload arbitrary code on the server. The resulting payload (for example, a shell written in PHP) may be executed with the privileges of the web server.
CVE (Common Vulnerabilities and Exposures) is an online dictionary of registered vulnerabilities that provides yearly statistics about known problems (see http://cwe.mitre.org/documents/vuln-trends/index.html). In 2001 the number one vulnerability affecting software was the well known buffer overflow; XSS, SQL injection and RFI were almost non-existent. In 2006 a clear shift towards web applications is visible: XSS is the number one vulnerability, SQL injection number two, and RFI number three. Buffer overflow has moved to fourth place.
Recommendations
Common ways to mitigate the risks related to web applications are detailed below.
If you are developing web applications:
• do not trust any content, parameter or variable coming from the web browser, and be sure to properly sanitize all input before using it;
• check all input by design, even if it is not directly visible to users;
• use the validation functions providedby your environment and avoid relying only on your own filters;
• if you use a development framework that provides some input filtering, do not solely rely on it;
• keep your framework up to date with security patches – it can be a target as well;
• beware of the information revealed or echoed by error messages/pages;
• requiring (re)authentication for privileged operations is always a good idea;
• keep your support lists private – thismay prevent leaks when a vulnerabilityis reported to your team; and
• aim to reduce the exposure of your web application and avoid directly exposing it in the site firewall; for off-site access, whenever possible, require that users connect via a gateway system, such as Windows Terminal Services or the LXPLUS Linux cluster, as documented at http://cern.ch/security/internet.
If you are using web applications:
• take careful note of security warnings from the web browser;
• whenever possible, disable Javascript/Flash/ActiveX; for example, for Firefox using the NoScript extension at http://noscript.net may help;
• avoid following links to sensitive portals, such as for e-banking, and type the URLby hand if possible;
• whenever feasible, log out as soon as possible and/or close the browser when the session is completed;
• use the more secure HTTPS protocol instead of HTTP if available.
More information is available from http://cern.ch/security.