WEB APPLICATION SECURITY: A LOOMING THREAT

The truth of the matter is that Web applications are highly insecure. The Gartner Group estimates that 75% of all information security attacks are targeted at Web applications, while the International Computer Security Association (ICSA) estimates this at over 66%. A different industry estimate puts 97% of all Web sites as vulnerable to some kind of attack. The FBI reports that businesses lose $6.6 million on average each time proprietary information is stolen (including costs of research, development and branding). The September 11th tragedy only magnifies the possible dangers. All kinds of American corporate and governmental icons are subject to a new kind of Terrorism: Info-terrorism. A May 2002 report by the US Congress Joint Economic Committee entitled "Security in the Information Age" paints a bleak assessment of the potential readiness of our nation's information security systems and calls for urgent remediation.

For individual corporations and organizations doing any kind of business on the Web, the damage can be monumental. Loss of revenue, loss of customer and partner confidence, litigation, and brand damage are but a few possible consequences of exposure. Moreover, a targeted, well-designed simultaneous attack on leading American corporations could literally bring the economy to its knees. We simply cannot be complacent about the threat. It is very real and it is here.

The Presentation tier is responsible for presenting data to the end user in a readable format.
The user may also interact with the application by changing or sending parameters back to the Presentation software. Software in the Presentation tier includes Web servers such as the open source Apache and Microsoft's Internet Information Server (IIS), and browsers such as Netscape Navigator and Internet Explorer.

The Application tier is the "engine" of a Web application. It performs the business logic such as processing input, making decisions, obtaining more data, and sending all this to the Presentation tier. Popular software at the Application tier includes "App servers" such as IBM's WebSphere, BEA Systems' WebLogic and the open source products JBOSS and Tomcat.

Finally, the Data tier acts as a repository for data required by the Web application and stores both temporary and permanent data. Typical data stores are relational database management systems.

Building a Web application then is typically a collaborative effort that involves Web graphic designers, HTML coders, Macromedia flash programmers, Java developers, legacy code keepers, network gurus and database experts. This very complexity usually consigns security issues to the back seat. For example, a graphic designer's imperative is to blend form with function and, for most designers, security is less a function than a feature. Network administrators focus on keeping the "network" clean by installing mechanisms such as firewalls and intrusion detection systems. The task of securing of the application itself is most often the job of the lead developer -- typically someone versed in business logic programming and not security. The finished Web site is an agglomeration of ideas and code from several parties most of whom do not consider application security a design priority.

A second major reason for the fallibility of Web applications is the application design itself. A typical specification will be reviewed in three major classes: Software Quality Assurance, Business Logic Usability, and Security. Unfortunately the Security design is usually tested for normal use and not with the intent to prevent hacking (highly abnormal use). For example, the specification will typically specify that incorrectly entered fields will generate an error message. This, however, is far from rigorous stress testing against malicious entry or even accidental errors spawned outside the realm of every-day use.

Finally, Web applications are insecure simply because they are a recent phenomenon. In the early days of the Web, sites were mostly informative and conducting transactions was a novelty. As the Application server became widely deployed, the rush to provide transactional services and the associated requirements of critical customer information was in full swing. Most of these new transaction based Web applications were deployed in the 1998 - 2001 time frame. No other major mission critical computing infrastructure has been deployed as quickly -- not the mainframe, minicomputer, the LAN, or even the personal computer. Thus the very immaturity of Web applications, an insufficient rigor in most initial application design specifications, and the complex, collaborative nature of Web application development and deployment collectively create vast potential vulnerabilities.

By comparison, the traditional types of information security categories require relatively simple, well-tested precautions. At the desktop for example, anti-virus products from companies such as Symantec and Network Associates are simple to buy and easy to deploy. At the transport level, encryption products provided by Cisco, Checkpoint and others, and authentication mechanisms from firms such as Entrust and Verisign can adequately protect data in transit. At the Network layer three types of products -- Firewalls, Intrusion Detection Software, and Vulnerability scanners -- also have a record of good performance. Indeed, most American companies now use all three classes of security products quite diligently and have incorporated these into their security defense arsenals.

Web applications, however, remain at considerable risk. There is no "standard" off the shelf product to remedy the intricate bundling of Java, JavaScript, applets and HTML coding, platform configuration, graphic design and deployment, all of which work in concert to form a Web application. In fact, by using Web based applications as a back door, malicious users can easily circumvent the carefully prepared defenses at the Desktop, Transport and Network layers.

• Attacks on the Web server. Since Web servers manage requests including items such as printing resources, hackers often send "piggy back" commands to gain Web server configuration parameters.
  
• Attacks of authentication mechanisms. These include automated password guessing attacks and spoofing tokens within a cookie by injecting a script, and SQL code injection to bypass password authentication.
  
• Attacks of authorization schemes. Many of these typically include obtaining an escalation of privileges or obtaining access to arbitrary files. Methods involved include requesting hidden objects using guessable names or tunneling privileged commands to the database server.
  
• Attacking session state management. Sessions need to be tracked especially for transactions, shopping preferences roles and so on. Attacks can include replaying state information to capture new privileges, or modifying the state information.
  
• Client attacks. Many different vectors can be used to stage attacks from clients. For example, comments hidden in HTML source code contain useful information about the server and can be easily exposed. Java Script objects and Active X controls, both of which can embed powerful tools for manipulating client side interfaces, are obvious sore spots. A major class of client attack is dubbed "Input Validation". Data inputs can attack an application in various ways. A forced error in page execution may generate informational errors that reveal SQL entries such as tables and directory paths. Irregular inputs may also run command execution characters that run arbitrary commands on, say, a UNIX web server. Cross-site scripting attacks place malicious code in locations where others can see the results. The malicious code might prompt users to place passwords in the designated area. Finally, buffer overflows involve throwing as much as possible against a single variable or field. The result may be an application crash, or an execution of arbitrary commands.
  
• Systems Management interface attacks. These can span Web server administration, Web content management, and Web based network and system management. The use of Telnet, a cleartext protocol used by some for remote Web-server management, is especially vulnerable to sniffing. Web content management hackers use mechanisms that connect the Web Server over the Internet such as FTP, Secure Shell (SSH) or even proprietary Microsoft protocols. Finally, there are Web based management interfaces in hardware products that can serve as portals for attack.

• Parameter tampering;
  
• Hidden field manipulation;
  
• Forceful browsing;
  
• Poorly configured web servers;
  
• Stealth commanding; and
  
• Cross-site scripting.
  
• SQL injection

However, in our experience, even the smartest tools require additional measures to ferret out security vulnerabilities. Much of the problem lies in the initial application design and subsequent code writing practices especially at the server level. Thus what is required is a comprehensive approach (including tools) for identifying Web application security exposures. What is required is a set of experts steeped in:

• Application architecture of complex, mission-critical systems;
  
• Application integration using a wide range of programming tools, Web servers, Appservers, databases and networks; and in,
  
• Code remediation. That is, technical developers and architects who perform exhaustive manual and automated checks through source code to spot deviances in secure programming practices.

The Primeon process for conducting analysis and remediation of Web applications typically includes:

1. A review of the application architecture
   
2. Code quality assurance review
   
3. Application testing under normal conditions using scanning tools like AppScan
   
4. Application testing under unexpected or abnormal conditions
   
5. Host OS and Applications server vulnerability testing
   
6. Collaborative review with the client to determine the scope of the problem
   
7. Application remediation or vulnerability resolution
   
8. Application re-architecting (if necessary)
   
9. New application coding (if necessary)
   
10. New code quality review (if necessary)
    
11. Informing clients of new security vulnerabilities (ongoing)

Contact info: info@primeon.com or 888.394.5225.