Typical Weak Points

Whether it’s an online bank, online trader or small online shop – the critical interface between the Internet and confidential corporate information is formed in web applications that “convey” the communication between the customer and the backend systems. From a hacker’s point of view, this presents a lucrative, and often unprotected, gateway directly to the goal – confidential corporate data. The motives being the financial gain from stealing confidential data, blackmail, and fraud.

Why are attacks on web applications often successful?

In order to understand why attacks on web applications are often very successful today, it's worth considering the following two core issues in more detail:

How come already existing traditional IT security systems like firewalls or intrusion detection / prevention systems don’t offer sufficient protection against such attacks?
What extra attack points do web applications have compared with classic, locally installed applications?

Application layer vs. transport layers

To answer the first issue it helps to take a look at the technical basics of communication on the Internet. This can be illustrated well using the ISO/OSI-7 layers model:

The data runs through all the layers and in each case is converted into layer-specific representations. The highest layer corresponds to the application level; here the data is processed, the layers below this serve merely to transport the data from the application to the server (and back again). In this way, the data is communicated from the application on the web server to the application on the client, the browser. Now the deciding factor: Ten years ago all the layers were unprotected – attacks on the lower levels of the seven-layer model were easy and very effective. In a response to attacks on these layers there came about the IT security solutions we know today, like firewalls and intrusion detection systems. With an increasing protection of the transportation levels on the one side – and for the motive reasons specified above on the other side – the application level itself became increasingly lucrative for attackers.

The conventional IT security solutions mentioned above – also historically determined – can’t check an HTTP request any further; if they were to block every HTTP request there would be no communication at all. So they must let through each HTTP request! In other words: the familiar classic IT security systems have been developed to protect communication on transportation levels – and they work well here. But they offer only negligible, insufficient protection to application levels. Added to this is the fact that the variety of web script languages offered, as well as application frameworks and web technologies generate a virtually unlimited number of security gaps – an ideal starting point for hackers.

Typical weak points of web applications

To answer the two core issues, we turn to the typical additional attack points of web applications. These are the core problems that exist as a result of the web-based nature of web applications. The following aims to illustrate the greatest problem areas.

Checking all entries

The majority of programmers and their programs have a very human problem: They trust the users of web applications.

The classic problem you get from this is the buffer overflow: A web application expects one word or one line as an entry from the user, and is therefore unprepared for the user to enter more than 1024 characters or even 2 GigaBytes of data. Then, all of a sudden, the input overwrites other parts of the program. In the area of web applications, a simple buffer overflow no longer plays such a great role, as they’re usually written in Java, PHP, Perl or other languages with an automatic memory administration. It’s merely the web server itself – and, in the past, frequently the SSL library – that’s susceptible to such attacks.

An exception to this of course being application servers that are written in C or C++. A good example of an application that had such problems in the past is the SAP web frontend. Here problems always arise if input data of the user (or the attacker) is passed on unchecked to other components of the overall system. This results in the problem class of the command injection attack; the most familiar here being the SQL injection. In doing so, an attacker can execute direct commands on the data base that usually belongs to the web application, or it can read out or manipulate outside data. Attacks on the operating system of the web server are somewhat older.

What makes this all the more difficult is that it isn’t obvious which data could be actual user inputs. Often it’s incorrectly assumed that the cookies set by the web application, hidden input fields or, for example, the name of selection boxes in a web form, can appear unchanged again as inputs. As a matter of fact in all these examples data can be freely manipulated by an attacker. Under some circumstances, the host name of the client itself can be used for attacks.

Session handling

In principle, the HTTP protocol is stateless. At the times of HTTP version 1.0, a query on a web server would be supplied as follows: The browser makes a connection to the server on network levels and sends to the server the URL of the required website. The server then returns a document and the connection ends. The next web page or even the images embedded in a web page are requested by a new connection. Generally speaking, in this regard nothing has changed in the protocol HTTP 1.1.

It’s true that the network connection is no longer regenerated for each request, but that several web pages are loaded via the same network connection. This, however, is just a performance optimization. From the point of view of the web application, the communication still consists of individual, independent queries. The web was originally conceived as a medium for publishing content. The idea of realizing more complex web applications like online shops only came about later on. An online shop must be able to detect associated HTTP queries as belonging together (belonging to a session). To do this, information must be passed on from one query to the next.

Often, these sessions aren’t especially protected, which means an attacker can assume an existing session of a different user (session hijacking). As authentication information is generally linked to this session, the attacker can then act on behalf of the outside user, e.g. buy things on his account.

State

Virtually every web application these days is stateful, which means there’s an internal status of the web application that’s updated during the course of use and that depends on the continued behavior of the web application. A simple example of this is the shopping cart when shopping online. While in the case of classic programs this status is implicitly given by the core image of the program at runtime, this status must be explicitly saved in web applications. As a rule, cookies or the parameters in the URL are used for this. However, these can be manipulated by users. The web application developer must therefore make a clear distinction between security-relevant and uncritical parameters. This distinction isn’t always easy to make. Therefore, it’s sometimes possible that an attacker edits the shopping cart of a web shop and can change the prices of the items. If the entire ordering process is automated, and no plausibility checks are carried out by humans, the operator of the web shop has a serious problem on his hands.

Internet vulnerability

Classic applications are only vulnerable if the attacker has access to the computer or the local network. There are reliable protective agents for this, like padlocks, user accounts, firewalls and intrusion detection systems. Unfortunately, these techniques have little use in the web applications area. The web application should, after all, be accessible for the entire world. This implies that it can also be attacked by the entire world. Many web applications rely on standard software packages. As soon as an error is found in this, within a short period of time this error can be automatically exploited in all the web applications. Virtually every website today is regularly scanned by attackers for known weak points or configuration errors in the administration. It's always worth taking a look at the server log files.

A further problem with network applications in general is the susceptibility of the connection between the client and the server, i.e. in this case between the browser of the user and the web server that’s executing the web application. If non-specific security mechanisms like SSL are being used, the communication between the user and the server is unencrypted, i.e. each provider on the route between the user and the web server can read the text and also modify it. Now, you could argue that Internet providers enjoy a certain amount of trust and they won’t change data. But what if a malicious attacker can link into the communication? Internet connections aren’t point to point connections between the client and the server. The data packages of a connection can be diverted – and a skilled attacker can make this connection run via his computer. These are the so-called “man-in-the-middle attacks” as the attacker sits between the two authorized parties. Technical solutions like encoding and authentication with SSL can help here, but they’re often used incorrectly.

Authenticity of the web application

Applications installed locally on the computer have a great advantage: The user generally knows precisely into which application he is entering his data. The user (or rather, the administrator) has control over the locally installed applications; as far as the user is concerned these are considered trustworthy. Local applications save sensitive data on the local hard disk of the user or on the trustworthy file server in the company’s network. It’s true, that with today’s spread of viruses and trojans, this ideal world is also threatened, but, on the whole, this image still applies. The web area is much more complicated. The user communicates with an outside application somewhere on the network. He has no idea where his data is being saved or whether it’s safe. Each year at least one scandal regarding millions of stolen credit card data hits the media.

But it gets worse: Even if the user of the web application or the operators are trusted in matters of data security (the majority of people trust, for example, in their bank) – in web areas the user can’t definitely detect whether he is currently in the “correct” application or whether he should hand over his confidential information to a web application that just appears to be legitimate. Under the names of phishing and pharming, this problem has become key in the web application security area. There are also technical solutions like SSL certificates; but unfortunately in practice these have proven to be inadequate.