Don’t forget the applications
Contributed by Izhar Bar-Gad, CTO, Sanctum, Inc. Contributed articles do not necessarily reflect the viewpoint of the ÆGIS e-journal.
It takes more than firewalls and intrusion detection systems to protect your Web-based applications.
You’ve installed a firewall to protect the corporate jewels inside your network. Likewise, you’ve got intrusion detection software so you can find out when someone is pounding on your servers, trying to get in. So you shouldn’t have to worry about anyone being able to tamper with your Web applications, right?
Not so fast!
Providing Web application security for an e-business is a huge and complex task. Today, almost every Web site can be broken into at the application level in a matter of hours, resulting in data theft, price alteration and site defacement. These exploitations are the result of flaws in internally developed code and third-party products. Attempting to plug all these holes requires a full-time security team to monitor and patch the applications.
This article discusses a new security technology that is essentially a run-time application-level security proxy. The proxy recognizes the application security policy for each Web page by constantly analyzing the outgoing traffic from the Web application to its clients. The proxy then enforces this policy on returning requests, preventing hackers from exploiting application vulnerabilities and removing the need to track and patch every hole in the application. This provides a higher level of security and reduces resource requirements within the organization.
Audits performed by Sanctum engineers on more than 70 major Web sites revealed all of them had major problems at the application level that could be exploited in a matter of hours. While heavily secured at the network level, these sites still allowed hackers to manipulate and exploit Web application vulnerabilities. Why? Because virtually all sites today attempt to achieve application-level security manually. This is a complex, time-consuming and labor-intensive task. Manual security measures include fortification of the application and its environment, as well as recurring tests. On the way to this ambitious goal, all Web site managers struggle with the same issues:
1. Flaws in the design, implementation and testing of internally developed code.
2. Vulnerabilities in vendor-provided application infrastructure.
3. Misconfiguration of underlying infrastructure.
4. Flaws with code obtained from external sources or outsourced code
5. Backdoors and debug options left open on purpose within the application.
Application hacking techniques
While it is difficult to secure Web applications, application hacking is quite simple. A hacker typically spends a few hours understanding the Web application, then attempts to interact with the application and its surrounding infrastructure in malicious ways. This hacking normally involves three simple techniques:
Manipulating Hidden Fields
Modifying supposedly hidden fields in a form is simple. If the price of a product is kept in a hidden field, for example, a hacker can follow a few steps, as follows, to change the price.
1. Open the html page within an HTML editor.
2. Locate the hidden field (e.g., “<type=hidden name=price_value=99.95>“)
3. Modify its content to a different value (e.g. “<type=hidden name=price_value=1.00>“)
4. Save the html file locally and browse it.
5. Click the “buy” button to perform electronic shoplifting via hidden manipulation.
Parameter Tampering
A hacker can exploit incorrect CGI parameters embedded inside a hyperlink to obtain access to any file he wants, such as password files.
Cookie Poisoning
Since cookies are not always cryptographically secure, a hacker can modify the cookie file, thus causing the return of information belonging to another user and enabling activity on behalf of that user.
Manual application security
To manually subvert these attacks, a Web site development team needs to go through a process that spans the entire organization and exacts a toll in each phase of Web site management. The process typically consists of the following phases:
Secure code design
Designing applications with security in mind, while always a good idea, can lead to a more complex application and extend development time.
Secure code implementation
Implementing a secure application requires the use of defensive coding to make sure an implementation error will not cause a security hazard. This process demands time—often an unavailable luxury in the world of Web development.
Testing for loopholes
In addition to functionality testing, the application should also be placed in hostile environments and attacked with various tests and inputs. This process demands an expertise that often does not exist within the organization, leading to expensive outsourcing.
Secure configuration
Attention to detail is crucial in this stage, as the configuration of each component should be checked, including servers, CGIs and internally developed code. For example, the site administrator should configure vendor software to turn off any unsafe features and set correct permissions on every accessible file.
Constant patching
Every time a vendor or developer announces a fix for a vulnerability, the patch should promptly be applied to the entire site. Keeping pace with the rate of the fixes, especially for complex sites, is difficult.
Education
Educating developers, testers, site administrators and external consultants to understand and master application security is a daunting task.
Code Reviews
Public domain software is widespread in the Web environment, and usually contains easily exploited security holes. Code reviews are needed to ensure its security properties. Code reviews are time-intensive and ongoing to deal with the constant advances in the software.
Due to the complex and constantly changing state of the product, manual application fortification is bound to fail in the long run. Also, because there are multiple design stages of application development, a security error might occur in any of the stages and affect the whole sequence. Even with the best implementation, a single insecure design stage is enough to cause the application to be vulnerable. Furthermore, because the sequence of stages must occur in “Internet time,” new security holes are likely to pop up often.
Implementing Web application security
Trying to patch all the holes manually is an impossible task. The alternative, then, is to simply refuse to allow hackers to exploit the vulnerabilities.
This is possible using technology that spells out in advance all acceptable responses defined in an HTML page, then forces HTTP requests to conform to an automatically generated security policy. Implemented on a server residing between the Internet and the application, usually behind firewalls and in front of the Web servers, such an application protection server functions like a proxy for bi-directional information flow of requests and responses.
When a user starts an application session by directing his browser to an e- business site, the application protection server first verifies that the page accessed is indeed a legal entry URL to the site. For example, the site administrator may declare the home page to be a legal entry URL as well as any page under the “products” section. After the initial check, the application protector creates a session token and stores it inside a cryptographically protected cookie. This cookie uniquely identifies users in all future transactions.
Once a session is established, the protection server analyzes each HTML page that belongs to that session as it is being forwarded to the browser. A policy recognition engine analyzes the page, looking for information such as CGI parameters, hidden field values and drop-down menu values. Through this run-time analysis, the application protection server automatically determines the security policy of the application. Additional legal requests cause the server to adjust the security policy for the session.
Enforcing the dynamic policy for every user is done using technology that reduces any request sent from the browser into a simple and secured language. This secured language representation is then used to rebuild a request, which is context dependent and subject to the security policy set by the policy recognition engine.
Reducing the request to its simplest form and then expanding it prevents any illegal information from being passed to the application. The process is analogous to that used to distill water. Contaminated water is boiled in one tank while the resulting steam is transferred to a second tank. There, it is turned back into water, with all its impurities removed.
In case of a hacking attempt, the reduction phase of the process will fail. The application protection server will then invoke a customizable error CGI with information about the origin of the attack and its type. In response, that CGI generates an error page, again customizable, that is sent to the hacker. A timeout CGI is also invoked in case a request is sent after a session is timed-out.
Using this kind of application protection means that errors created throughout the application development, testing and deployment stages will not cause security breaches within the Web site. Nor would any security holes in third-party or public domain applications. This change in the security environment enables the organization development process to shift away from security and to its true focus—adding greater functionality to the Web site. The result is a more secure Web site that is built more quickly.
Izhar Bar-Gad is CTO of Sanctum, Inc., a vendor of Web application security and control software. More information about Sanctum may be obtained by visiting http://www.SanctumInc.com/ or by calling the company at (408) 855-9500.
