One of the emerging buzzwords of 2005 is "application security" but many managers still don’t have a clear picture of what the term means. Security vendors are not helping as they all clamor for a piece of this emerging budget line-item with very diverse offerings.
To understand what it means to secure an application, it helps to understand why everyone is trying to secure them, and what they're securing them against.
The reason application security is becoming an important priority for corporations is that a company's applications, specifically its web-based applications, are the currently the "path of least resistance" for hackers. Simply put, it's the current weak link in most corporate security chains. Just as Willy Sutton once famously quipped that he robbed banks because "that's where the money is" hackers today are attacking web applications because that's where the data is. Companies have made an unprecedented amount of information available to an unprecedented number of people thanks to the web, and hackers are taking advantage of that. They realize that any application which can access one person's account information can, by definition, access anyone else's account information. Tricking the application itself, then, is an effective way to gain access to restricted files.
So how does it work?
Most hackers are taking advantage of some fundamental security weaknesses in the way web applications work. For instance, most web applications were developed and tested using methodologies created for client-server applications. In some cases, they started out as client-server applications and were 'ported' to the web, a process that often consisted of little more than reproducing the client GUI in a browser. In other cases, they were developed for the web but their coding and testing practices did not incorporate the unique challenges of web security.
For example: client-server applications had a stand-alone, installed piece of software on the user's computer. That software client was hardened and obfuscated; it was very hard to tamper with it. When companies ported that application into a web browser, the GUI might have been replicated, but the security typically was not. Any user can simply view the page's source in a web browser to see all the client-side code. A clever hacker can easily determine exactly how requests are being made to the server, and alter that code to make different requests.
To make matters worse, the client-side code is typically used to 'trusting' requests that come from the client. After all, that client was supposed to be secure. So once hackers take control of the client code, they can access anything that application touches.
One more example of the dangers of porting client-server applications to the web. Client-server applications used to do a lot of data validation on the client, to cut down on bandwidth and server processing. Web applications try to use scripting languages such as JavaScript to do similar data validation in the browser, but browser code is too easy to access, disabling or tampering with JavaScript. In other words, any validation or checks that developers can put into a browser, users can simple disable or change. This places the entire burden of input validation on the server side, and most programmers don't have the time, patience, or training to check every single input for potentially malicious values.
This aspect of web applications exposes them to attacks such as Buffer Overflow, SQL Injections, and Cross-Site Scripting. For instance, users can take advantage of input fields in web-based forms to input malicious code. Instead of typing in a name or address, they input code which executes on the server, giving them unfettered access to restricted data.
The second major difference between the old client-server environment and the web has to do with state or session persistence. Simply put, this just means remembering who a user is when they click from one page to the next. In client-server environments, a continuous session is maintained between each user and the server, so this is not a problem. Web environments, however, have no session persistence; users request a page and then disappear from the server's view until another page is requested.
This opens the web application to many types of attack. The most common is forceful browsing (also called broken access control). This attack consists of simply asking the web server for pages or resources which should be restricted. In some cases, it might be bookmarking an internal page of an application, then jumping to that page later without first passing through an authentication page. In other cases, users might guess the URL of information they want to see. For instance, they might try to find pages located in /admin or /config directories by using common default filenames.
Another inherent limitation of the web's statelessness is that, in order to keep track of users, web applications must leave something in the browser that identifies the user and the types of information requested. For instance, if the web server leaves a hidden field on the page with a price or user group information, you can view the source of the page, change it, then resubmit the page. The most common way to track users is the employ session cookies. Just like the other methods, however, a cookie resides on your PC, so you can find the file, open it, and change it.
So what can companies do to mitigate threats like these?
Fundamentally, managers have two methods for dealing with these types of vulnerabilities. The first is to write explicit safeguards into the application code itself. There are no shortage of consulting firms providing training and frameworks for so-called "safe coding" initiatives and they are making applications much better than they have been historically. In addition, application development platforms are introducing more tools to help developers do things like validate inputs to prevent SQL injections. Of course, all of these tools are only as good as the developers implementing them, and are useless if they are not enforced. Furthermore, it's impossible to code against platform vulnerabilities. For instance, a system or configuration file left exposed on a web server can be accessed by forceful browsing to a known or likely address for that server platform.
Furthermore, most firms have dozens if not hundreds of legacy web applications which are rife with vulnerabilities. An ideal solution to the problem would offload application layer security to a centralized device where it could be easily managed and audited. This device would provide cost-effective, high-performance, pro-active application layer security from both generalized and targeted application attacks.
Products like these are now appearing on the market. Commonly called Application Firewalls, they consist of a reverse proxy that sits in front of web servers and checks each request for malicious content or forceful browsing, passing only legitimate traffic to the Web servers behind them.
Of course, there is no magic bullet to the problem of web application vulnerabilities. A layered approach is required including better coding, tighter integration of development and security infrastructure, and application-aware network devices to do some of the heavy lifting.
Unfortunately, the problem of web application vulnerabilities is not going away. Indeed, as enterprises become more tightly locked down at the network level and continue to put more information on the web, application-level attacks will become increasingly common. Already an abundance of hacker web sites provide tutorials and even shareware programs to facilitate this activity. Enterprises, in turn, must build out their own defenses. As more options become available, managers need to be smart about what 'application security' really means and how best to secure their most valuable assets.
The author is director of security products at F5 Networks
