Content

Hot or Not: Web application vulnerabilities

There's no doubt that web applications have become the attackers' target of choice. In September, Mitre Corp.'s Common Vulnerabilities and Exposures list - a tally of publicly disclosed vulnerabilities - ranked cross-site scripting in the number one slot. In fact, cross-site scripting attacks surpassed buffer overflow vulnerabilities. And four of the top five reported vulnerabilities proved to be within web applications.

Whether targeting collaborative Wiki's, portals, or the web applications that provide access to backend databases and banking applications, these vulnerabilities provide an ample attack vector. Not only for the information stored within the web application itself, but as a launch pad to internal network segments and servers, and even end user systems. That's why it should come as no surprise that in the recently published SANS Institute Top-20 Internet Security Attack Targets 2006 Annual Update, web applications topped the list for Cross-Platform Application vulnerabilities. And by some security industry estimates, web applications are currently targeted in nearly 80 percent of all attacks.

It's easy to blame lazy developers for porous application security. But that's an overstatement. The fact is that developing web applications is intricate, and the combined complexity and flexibility of web development tools, such as Java, .Net, Perl, PHP, Ruby, and others, make it easy for development mistakes to become exploitable security holes.

Here are some of the most common:

  • Cross-Site Scripting (XSS): These attacks are made possible through web applications that let attackers inject their own HTML code and even downloadable scripts into legitimate web pages. Through XSS attacks, websites can be defaced, become vectors for malware propagation, and even be used to hijack a user's system. These vulnerabilities make it possible to deface websites, insert malware and take control of a user's system with JavaScript. A special type of XSS attack, known as Cross-Site Request Forgery (CSRF), can make end users execute commands without their consent.
  • Directory Traversal: The attacker's goal here is to access files he or she shouldn't be allowed to see. It's done by exploiting poor security controls surrounding input file names. The attacker then can access unauthorized information, including password and configuration files that can be utilized for attack escalation.
  • SQL Injection: In these vulnerabilities, attackers take advantage of poor filtering controls for database commands. SQL Injection attacks can lead not only to compromise of the database, but in some cases the server and surrounding systems as well.
  • PHP Remote File: Default implementations of the popular PHP framework allows file functions to access Internet resources. And when PHP scripts are crafted to allow user input to influence file names, all types of bad things are possible — including remote code execution, installation of malware, including root kits and other attacks.

The common thread among these vulnerabilities, and most problems with web application security, is that they're developed without proper security checks throughout the development lifecycle.

The good news is that, because many web application vulnerabilities are unique to a specific site or application, attackers are forced to work harder to infiltrate individual sites. But the flip side: because all vulnerabilities are slightly different, they're more difficult for web application security scanners to identify: There is no single signature that will spot all SQL Injection vulnerabilities.

And that's one of the reasons why web application security is so thorny. Because there's no single solution that would rid web application vulnerabilities, securing these applications requires a systematic approach, and multiple layers of quality and assurance, and security testing. The first place to start is by testing for Web application vulnerabilities as soon as coding begins. Catching these errors early in the development process not only closes the security gap; it's also more cost effective than having to revamp an application already in production.

After initial development is complete, and applications are in production, web servers and associated systems should be scanned periodically for vulnerabilities. A system without vulnerabilities on Monday can be highly vulnerable by Wednesday. And it's an excellent idea to install intrusion detection systems on web servers, as well. Because of the very nature of web application flaws, attackers may have to perform multiple attempts to compromise a system; and a properly deployed IDS is likely to pick this up.

Because of their complexity, developing and maintaining secure web applications is — at best — a challenging proposition. But reasonable levels of security can be achieved by making security a priority from application conception, throughout development, and while they live in production.

Programming languages and techniques are always evolving, as are attack methods. That's why continuous training and awareness programs for novice and expert developers alike is crucial. So make sure your developers and security audit teams stay informed through security training courses and associations. The Open Web Application Security Project, OWASP, is a good place to start learning about web application security—and the OWASP Guide: A Compendium of Secure Coding is a must read for web application developers. The zero-day attack averted as a result of improved development techniques just may just be within your own organization's web applications.

- Amol Sarwate is director of Qualys' vulnerability research lab

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.