Every year, companies are gradually moving their mission-critical applications and data into web browsers. The reasons are obvious: browser-based applications are easier to roll out, support and maintain. As browsers and client scripting languages become more powerful and web services become a standard, the trend is likely to continue. Indeed, even major industrial enterprise applications are now web-based.
Unfortunately, many features that make browsers so convenient and cost-effective also make them incredibly insecure. As a result, hackers are able to use web-based applications to penetrate corporate systems and access restricted customer records.
This article will explore some of the underlying reasons for these vulnerabilities in web applications. It also sets to illustrate some of the ways hackers commonly exploit them, and suggest several ways in which companies can mitigate their risks.
Root Causes of Application Vulnerability
Many of the most dangerous security holes in today’s applications are neither based on worms, viruses, nor known vulnerabilities in application servers, but rather vulnerabilities in the applications themselves. These vulnerabilities, unique to each application, leave company web infrastructures exposed to attacks such as cross-site scripting, SQL injections and cookie poisoning. An industry group called Open Web Application Security Project (OWASP) has produced an excellent list of some of these types of vulnerabilities, which they call their ‘Top Ten Application Vulnerabilities’. These lists are generally produced by security vendors to highlight their own particular strengths. Other such lists also exist, and they all identify the same general types of vulnerabilities: browsers were simply never designed to validate the requests generated by users in an application.
Rather than list all the most frequent attacks, it might be useful to ask: what is the common thread among all these attacks? In other words, are these known attack methods just symptoms of some more fundamental limitations in web applications?
Fig. 1: New threats to the enterprise
The root cause of most application vulnerabilities today is their heritage. 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 web 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.
Why is this a problem? It is a problem because web applications have a distinct set of security challenges which are not obvious if you grew up in the client-server world.
Consider the paradigm of the old client-server development environment. The process of developing and testing client-server applications was modified, optimised and refined for decades, resulting in very robust applications. These applications consist of server and client codes written and intended to work together. Deploying and maintaining client-server applications, however, remained very expensive. Clients had to be tested on multiple operating systems, and installed on every client machine. They had to be re-installed whenever there was minor version change of the software, and so on. The cost of deploying new applications or maintaining existing ones for large number of users eventually became unmanageable.
To save money on deployment and maintenance, businesses have moved many, if not most of their applications to the web, often making minimal changes to the server while porting the client into a standard web browser. Deployment is now free and clients are now platform-independent. However, the companies have exposed themselves to tremendous risk; the server code expects to have a trusted client but in fact has a web browser client. In order to understand why that is so dangerous, let us look at the key differences between the two models.
Key Differences Between Client-server and Web
Fundamental differences between web and client-server applications open enterprises to significant risks when they move to the web. For simplicity’s sake, we look at two major ways these applications differ.
Heavy Client vs. Browser
The heavy, purpose-built clients used in client-server applications are difficult to reverse-engineer, hence it was difficult for hackers to modify inputs to the server. Think about it: when you have a piece of software running on your PC, you have no way of altering the messages it sends to its server. The software has fixed buttons and widgets, with no way to access the underlying code and manipulate the commands it generates. Browsers, however, are very easy to manipulate. The source of the client side code is available to anyone accessing the web page, and easy to modify. Users can simply go to “View Source” under the “View” menu of Internet Explorer or other browsers, change the code, and then reload the page. In fact, some hacker websites now even offer tools such as ‘web proxies’ which automate this type of manipulation.
To improve server performance, reduce network traffic, and enhance user experience, client-server applications carry out a lot of data validation on the client side. Web servers try to utilise the browser’s capabilities (HTML and JavaScript) to do data validation on the client, but HTML can be changed and JavaScript can be disabled. In other words, any validation or checks that developers can put into a browser, users can simply disable or modify. This places the entire burden of input validation on the server side as most programmers cannot afford 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 enter malicious code. Oracle recently announced that Oracle Application 11i, their most web-friendly enterprise software to date, had left several inputs invalidated and open to tampering. An online auction site discovered a particularly nasty vulnerability in their e-commerce application. Malicious users were listing auctions with dangerous JavaScript commands in the item descriptions. Since the auction software was not inspecting what people entered into their descriptions, all these JavaScript commands were being served up to anyone who clicked on the auction. Through the execution of their browsers, new windows were opened, and cookies stolen, and so on. This is a classic cross-site scripting attack.
State vs. No State
Let us look at the second major difference between the old client-server environment and the web. In client-server environments, a continuous session is maintained between each user and the server. Once a user logs into the application, an unbroken connection feeds the user appropriate information. In web environments, there is no session; users request a page and then disappear from the server’s view until another page is requested.
This opens web application to numerous 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 you should not have access to. In some cases, it might be book-marking an internal page of an application, then jumping to that page later without first passing through an authentication page. A well-known financial services company encountered this problem recently. Users could literally bypass the login page if they knew the address of internal pages.
In addition, users can sometimes guess the URL of information they want to see. Lately, a major record label also released a “sneak preview” – the first song of an upcoming album with a URL ending in /track1.mp3. Obviously, it was not long before the young audience realised that if they only need to type in “track2.mp3” or “track3.mp3” to access the entire album.
Somewhat more seriously, the Minnesota State Police Department discovered that anyone could append “/personsearch/personsearch.asp” to one of their public website addresses and access the department’s police records. (They have since fixed the problem.)
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 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 page’s source, modify it, then re-submit the page.
The most common way servers track users is session cookies. Again, a cookie resides on your PC, so you can access and change it. Lee Gomes of the Wall Street Journal recently exposed this flaw at Gateway Computer. As Gomes reported, users could change their cookies and, when they went back to www.gateway.com, they were greeted with “Welcome back, x” and were able to access x’s credit card information, address the works. Change the cookie again and you would be ‘recognised’ as someone else!
What Can be Done?
Today, there are two ways of dealing with these vulnerabilities. The first is to write explicit safeguards into the application code itself. There is 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. Furthermore, application development platforms are introducing more tools to help developers do things like validate inputs to prevent SQL injections and the like. Microsoft has introduced Web Form validation controls and Java now has tools such as Struts to provide similar capabilities. Of course, these tools are only as good as the developers implementing them, and are useless if they are not enforced. Additionally, it is 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.
Fig. 2: Securing web applications
Most firms have dozens, if not hundreds of legacy web applications which are rife with vulnerabilities. An excellent place to begin making your application better is with scanning tools (SPI Dynamics’ WebInspect product is my favourite). These can help to identify vulnerabilities in applications at both the platform and code level.
However, an ideal solution to the problem would offload application layer security to a centralised device where it could be easily managed and audited. This device would provide cost-effective, high-performance, pro-active application layer security from both generalised and targeted application attacks.
These products, generally called application firewalls, are 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. Application firewalls can block against vulnerabilities discovered by scanners like WebInspect (shared using AVDL, an open source application vulnerability description language). Alternatively, they start from scratch and create their own map of the application, blocking all non-recognised requests.
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 place more information on the web, application-level attacks will become increasingly regular. Already an abundance of hacker websites provide tutorials and even shareware programs to facilitate this activity. Enterprises, in turn, must build out their own defenses. Until they have an application security strategy, they are no more secure than a castle with its front gate wide open.
Andrew Stern is the Director of Security Product Marketing, F5 Networks. He brings ten years of technology marketing and business development expertise to F5 Networks. He is a recognised expert in the web security industry and frequently lectures and authors articles on the subject. Within F5, Andrew is responsible for evangelising TrafficShield and related web security products, working closely with F5’s field and channel sales teams to educate customers on web application vulnerabilities and emerging best practices.
Links & Literature
• OWASP’s “Top Ten Application Vulnerabilities”: www.owasp.org
|
