Most Common Web Application Security Threats

Welcome to the Information Age! Right from the Industrial Revolution, man has made immense progress in science and technology which gave rise to a whole new explosion of goods and services. This has given rise to globalization and the opening of new markets and the rapid growth in economy. And then came the era of computers!

The progress in technology now became immeasurable. People began doing business a whole new way. New methods of communication were established, the size of the silicon chip became smaller and smaller and the capacity to store information became larger. With new communication methods, networks of computers became larger and immense, and almost every household was made connected to what we now call the Internet, the information super expressway!

In today’s world information is the buzzword. Since time is money, information which saves people time is the most valued. Organizations are willing to pay the top dollar for information and products which increase sales. People will want to purchase food items, book movie tickets, wire money to a friend or relative, pay utility bills, plan vacations, schedule appointments, and send emails, network with friends and even make long distance calls! These, and many more things have been made possible only because of the power of the Internet. No doubt, the Internet was the biggest technological leap man has made.

As every coin has two sides, so does the Internet. With the conveniences, came the uncommon threats to security of information. Nowadays, thieves do not come and rob a bank. They would rather want to have the comfort of their homes and virtually rob it, just with a computer, some knowledge of networks and tools, and an Internet connection! With the easy flow of information, it has been easier than ever to know how to breach security. With some knowledge of software development and networks, attackers are now able to create tools that will help them exploit security loopholes, breach rules and policies and finally help gain the object of desire.

All of this paints a very gloomy picture. But the good news is that there is a non-for profit organization by the name of the Open Web Application Security Project (OWASP) Foundation which dedicates all of its efforts in improving software security, especially the web and the mobile. They annually come up with a list of the top 10 vulnerabilities or threats against software security.

Let us take a look at the same and understand the most common threats to application security. OWASP TOP TEN

1) Injection

This is a common vulnerability. What it really means is that the application allows execution of code through externally sources, thereby ‘injecting’ it into the mainstream runtime code, maybe from text fields. For example, consider the following block of code:

String query = “select * from accounts where customer_id = ‘” + request.getParameter(“customer_id”) + “’”;

As you can see, the customer_id parameter would be accepted externally, maybe from a text box. What if an attacker entered the following value in the text box?

1001’ or’ 1 = 1

This will eventually be sent to the server to execute. The newly added or condition changes the meaning of the query and will force the server to return all account details. The attacker ‘injected’ the query externally through a text box and got access to information which he is not supposed to. This was an example of SQL injection. Similar such attacks could be performed on XML, XPath, No-SQL, LDAP, SMTP headers as well as system-level commands. Hence it is always advisable to strongly validate all input fields to minimize the risk of injection attacks.

2) Broken Authentication and Session Management

What are sessions? Since HTTP is a stateless protocol, most websites want to save the user information once he/she logs into the system. In order to do that they implement what is commonly known as a session. A session tells the website that a user is an authentic one and could be serviced further. Let’s take an example to understand how broken authentication and session management attacks are made.

Consider a website which displays session id in their URLs, like this, after a user has made the purchase:

http://abc.com/sale/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop

Let us also assume that the session id also stores information like credit card details, payment info, etc. What if the user who has made the purchase, sends this link out to his friends to let them know that he received a discount? If proper session management is not done, all his friends will be able to access his session id and make payments on his credit card, as the session would not have been destroyed.

Sessions should always be unique to every authentication attempt. They should be properly destroyed. If a user remains idle in his browser, the session should timeout and prompt the user to re-login. Also it is always encouraged to enforce strong password policies to discourage attackers from attacking a stolen session.

3) Cross-Site Scripting

Modern web applications use technologies like JavaScript, ActiveX, Silverlight, Flash, Node.js, etc. to leverage the browser’s power and enhance user experience, as well as to perform some server-side processing. Other than tweaking the user interfaces, these technologies also help developers get important information like session ids, etc. during a transaction. Cross-site scripting, or popularly known as XSS is an example of an injection attack wherein an attacker is able to inject malicious code snippets to get important information, or perform other malicious tasks.

An attacker may hijack a website and inject some malicious scripts, which get exposed to a user’s browser. If a user visits this website, his browser will execute that malicious code. To explain this further let us take an example.

Consider a user who logs-in to his Internet banking account. At the same time he has also opened a malicious website in another tab. On that website, there is an image link which contains following code:

<img src=”xyz.com/img.png”><script>maliciousBlock();</script></img>

What if the maliciousBlock(); function hijacks all the currently opened sessions? This would mean that the attacker could gain access to the user’s Internet banking portal session as well. We all know the eventual consequences.

4) Insecure Direct Object References

After authentication a user gains access to resources which he/she is authorized to. However, due to some inefficient access control mechanisms, the user may be able to gain access to some resources which he /she may not be authorized to. This is what this vulnerability is important to be addressed. Let’s take an example.

Consider the following URLs:

http://www.abc.com/users/williamtell/item1/edit

http://abc.com/users/admin/item1/delete

With these let’s assume that the user William Tell has rights to edit an item – item1. The user admin has a right to delete the same item. What should happen if William Tell hits the following URL?

http://www.abc.com/users/williamtell/item1/delete

The item1 would most probably be deleted if access control mechanisms are not implemented properly.

5) Security Misconfiguration

This is a serious vulnerability which can completely compromise systems. Let’s take some examples to understand how security misconfiguration can be disastrous.

During staging phase of a web application, the administrator forgets to remove the default Microsoft SQL Server user – ‘sa’ which has the default password ‘sa’. After the staging phase, the web application was deployed to production as a bug fix update. An attacker can gain access to the web application using the default Microsoft SQL Server account.

When a web server is installed, administrators forget to remove the admin user as well as dispose of the admin login pages too.

Administrator forgets to disable stack traces as well as directory listings.

An administrator forgets to remove the read-write-execute access on some web folders.

All of these and many more security misconfigurations allow attacker to completely compromise the system. Nowadays pre-configured or hardened servers are made available for easy production deployments.

6) Sensitive Data Exposure

Sensitive data is that data which if exposed will allow an adversary to take undue disadvantage of it. This might mean information like credit card details, passwords, personally identifiable information, transaction details, classified information, etc.

One of the most common examples is that systems fail to encrypt the data in transit with strong algorithms. Some websites fail to continue to use the SSL protocol for an already authenticated user. This allows an attacker to monitor authenticated sessions and sniff sensitive data. Sometimes passwords stored into the database may simply be stored in clear text format. An attacker may inject code to reveal the decryption logic and allow him to view sensitive information.

Therefore, one of the best ways to prevent data leaking, is to enforce strong encryption.

7) Missing Function Level Access Control

Should a non-admin user get access to admin-only privileges? Most probably not. Access controls play a major role in many of the web applications. You will find that web applications are user-intensive systems and comprises levels of users in their design hierarchy. The main idea is to protect information assets from unauthorized access. A simple user should not be able to delete another user account. Similarly, an administrator account should not have permissions to withdraw funds from a user’s account just because he is the super admin. These are some examples of access controls in place.

Let us take a simple example. A user is able to add an item to a list after clicking on the Add button. Besides the Add button lies the Delete button, which is always disabled for the user, but enabled for the admin user. The user is a malicious attacker, and he simply opens the web developer toolbar by pressing the F12 key. He locates the Delete button and he finds the following:

<button id=”Delete” class=”disabled”>

He changes the code to the following:

<button id=”Delete” class=”enabled”>

The button is now ready for a click. Should the click of this newly enabled Delete button actually make the deletion of the item from list? It would probably do the deletion, if proper access control checks are not in place.

Therefore, it is always advisable for the user to be re-authenticated every time an action is being made.

8) Cross-Site Request Forgery

This is one of the most common and successful attacks. In this, an attacker forges a malicious request and sends the same in the form of images, links which deceives the user to do something that the attacker wishes. Trojan horses are a popular examples of these attacks. Attackers are able to create malicious requests on behalf of the user’s browser, which the website under attack trusts. Attackers take the advantage of the users’ ignorance of the URL which he/she is currently accessing. Modern web browsers now show tooltips whenever a user hovers over a link. This tooltip contains the URL which the user would be visiting, if he/she would click on it. Novice users usually do not take a look at this and attackers take full advantage of this. Similarly, certain links or UI components do not always show the tooltip URL status. Therefore it becomes difficult for even a power user to know in advance which URL he/she would be opening.

Another example is spam email. Users can click on something accidentally to a malicious URL.

Let us take an example of a possible bank account amount transfer. Consider the following URL:

https://www.bank.com/transfer.do?ToAccount=123456&amount=1000

This URL will transfer amount of Rs.1000 to account number 123456. Let’s also assume that this will only work when a user is already authenticated. Now, if an attacker forges a URL like this:

https://www.bank.com/transfer.do?ToAccount=98765&amount=1000

It should transfer amount of Rs.1000 to the attacker’s bank account. He only would now have to make the user click on this link. For that he forges it by covering this up with a nice attractive discount, similar to like this:

<img src=attractive.png>

<a href=”https://www.bank.com/transfer.do?ToAccount=98765&amount=1000”></a>

</img>

And then he makes this link available across many public forums, discount websites as well as emails to a large list of vulnerable users!

9) Using Components with Known Vulnerabilities

Often times it so happens, in the race against time for software delivery, developers download some open source libraries and use them in their current development project. What they do not realize is that the libraries they may be using may be already obsolete, or contain known security bugs. Also the developer may not be using the updated versions of the libraries. These vulnerabilities eventually creep into their final product which gets delivered.

Most recent example was the notorious Heartbleed bug which affected the popular OpenSSL cryptographic software library. This was a memory leak bug which allowed anyone to read the protected contents. Since OpenSSL is widely deployed on the popular Apache HTTP Server and Nginx web servers, most of the web was practically under attack! If a developer fails to update his version of OpenSSL to the newer one containing the bug fix, it is plain simple that his web application would become vulnerable.

10) Un-validated Redirects and Forwards

Sometimes web applications contain re-directs or forwards to control user’s navigation to pages lying in external domains.

Redirects happen on the browser side. When a resource is requested, the server redirects the user to a different resource by giving the browser the URL of that resource.

A forward on the other hand is handled entirely by the server. When a resource is requested by the browser, the server handles the redirect internally and the browser is directly taken to the new resource. Both these approaches are okay as long as they are properly validated. If they are not, then an attacker can hijack them and, similarly to a cross-site request forgery, can change redirect or forward the user to a malicious website.

Consider an example wherein the user is redirected to the merchant, after carting his shopping, now come down to payment. What if this redirection is hijacked by the attacker? The user is redirected to the attacker’s page which might look exactly like a merchant page. The user is obviously successfully tricked into filling his/her credit card details, and away goes his money!