Web Application Hacking: Exposing Your Backend

We used to have simple web sites. The web server sent HTML to the browser which displayed it. This was a “brochureware” site; designed for marketing or advertising. There was no business data anywhere near the web site.

Now we no longer have web sites, we have web applications; and soon, web services. Web applications reside on multiple systems in distributed architectures, using sophisticated programming languages. Corporate and customer data has been moved to the computing edge. The edge has been extended to mobile phones, PDAs, mobile sales force systems, inventory management systems, etc.

Web applications invite public access to an organisation’s most sensitive data. Customer information, transaction information and even proprietary corporate data can be accessed through web applications.

Access to the application must be allowed by firewalls and access control lists, otherwise the application won’t work. This inherent trust is precisely what hackers attempt to exploit.

We secure our web sites by hardening and protecting the servers and restricting access from the outside. However, the web application has to be accessible to the public. The web application itself contains many vulnerabilities that may be exploited. Traditional perimeter security cannot help secure the application, since application vulnerabilities are exploited over HTTP.

Web applications breach the perimeter and provide direct access to customer and business data on backend databases.
Recent incidents include a hacker gaining access to more than five million Visa and Mastercard accounts in February 2003; the Record Industry Association of America hacked seven times in six months; a vulnerability at Tower Records allowing anyone to view the customer orders database in December 2002; and Ziff Davis paying $500 to its customers after lax security exposed personal data of thousands of subscribers.

The Problem

The problem is that, by and large, security professionals don’t understand web applications, whilst frequently application developers don’t know security. It’s an old story in new clothes. Even when web application audits are required, the lack of effective tools has made them impractical. Frequently security is entirely absent from the application development cycle. Security departments scrutinise the desktop, the network, even the web servers, but the web application escapes examination.
Web application vulnerabilities occur for many reasons. Of primary concern is the focus on functionality at the expense of security. The lack of security awareness and any form of audit during the development cycle is a serious handicap. Even in development teams that are security-aware, there has been a lack of effective testing tools, as well as severe resource limitations prohibiting code reviews.

The bottom line is that development creates functionality and QA tests that functionality. Security is missing entirely.

The Vulnerabilities

Web application vulnerabilities occur in several different areas of the application. The web server itself is subject to a variety of known (published) vulnerabilities, all of which must be patched. The administration of the server and its contents is important. A misconfigured server or poorly managed content can permit system file and source code exposure.
The application itself is of the utmost importance. It can inadvertently reveal source code and system files too, and even allow full system access. It can mistakenly permit replay attacks against customers, or customer impersonation exploits. In addition, the web application interacts with the database to manage and track customer information, and store business and transaction information. One mistake in the application can expose the entire system and database, right through a web browser, right over port 80.

Known (published) vulnerabilities in web servers are obviously a great source of risk, but perhaps the most easily defended against by patching. The difficulty comes from having to install patches on many servers. Streamlined patching procedures are essential, as are server inventories. If a patch is missed, a hacker will let you know!

Administrative issues are less easily corrected than published vulnerabilities. This requires a security awareness in those who manage the web site and its content on a daily basis. Clearly directory browsing should not be enabled anywhere, and the correct access control lists (ACLs) applied to every directory and file. This is more than just configuration, the implication of content is critical too. For instance, remnant files such as “readme.txt” or sample applications can reveal the applications and versions in use. Of course, commercial applications have known vulnerabilities too, just like web servers and operating systems. Backup files or improper application mapping can reveal source code, including the information necessary to connect to the database.

The application logic itself must be careful constructed and must include security mechanisms. Input should never be assumed to be what was expected. It must be tested, validated, and filtered. Applications that call up files, especially directly from the file system, must be carefully checked. Its too easy to expose source code, or worse yet, system files. Anything that even resembles javascript or vbscript must be removed. Inadvertently storing scripts entered by a hacker will allow them to be replayed against customers, resulting in the web site attacking customers or divulging session information to the hacker. All error messages must be handled. Unhandled (raw) error messages are a roadmap through the application and database. Database calls must be structured carefully, and any user input that will used in the query must be scrutinised. Carefully constructed input could allow a hacker to piggy-back legitimate queries with their own, giving them access to the database through the web application.

Security throughout

The management of web application vulnerabilities must occur in several different areas.
Security must be brought to the web development team. Create and enforce secure coding practices. Assess the code while its being developed, to identify insecure techniques before they are replicated. Ensure that QA test for security as well as functionality. Think security during change control procedures – don’t consider just the functional and performance impact of changes, consider the security impact as well.

The security department must learn application security. Create and promote internal awareness campaigns. Work with the development team to develop and publish best practices, and enforce those best practices. Create procedures to work with development to remediate vulnerabilities. Audit production systems frequently and with each change. Baseline and trend the results to gain a historical perspective of application security. Implement web application security assessments into Certification and Assessment programmes. Most importantly, assess applications in depth. Ensure the security is ‘baked-in’, not ‘brushed-on’.

Automated assessment tools can help introduce and maintain security throughout the application life cycle. Best of breed tools include: WebInspect from SPI Dynamics, AppScan from Sanctum and ScanDo from KaVaDo.

First Base Technologies are exhibiting at Infosecurity Europe 2004 which is Europe’s number one IT Security Exhibition. The event brings together professionals interested in IT Security from around the globe with suppliers of security hardware, software and consultancy services. Now in its 9th year, the show features Europe’s most comprehensive FREE education programme, and over 200 exhibitors at the Grand Hall at Olympia from 27th to the 29th April 2004.