Designing Security in Web Applications

9

Designing Security in Web Applications

Andrew Tomkowiak

10/30/13

Software Engineering

University of Wisconsin-Platteville

Abstract

In this day and age society is constantly connected with the internet and visiting a variety of websites. People are ordering more and more off of the internet. They enter personal information such as their addresses, phone numbers, and credit cards, which leave them susceptible to attack. As software developers it is our responsibility to make sure we take every precaution to protect the users of our web applications from malicious hackers. This paper will cover basic design principles and security threats to be aware of when designing web applications.

Architecture and Design issues

The dynamic nature of web applications offers user’s unique experiences however it makes it more difficult for the application to determine the users’ rights, rights that outline a user’s level of access [2]. This is the base point in web application security: being able to establish definitive boundaries when it comes to user access. Web applications have a multitude of vulnerabilities that can occur due to designs without established limits or incomplete designs.

Some possible vulnerabilities:

·  Input Validation

·  Authentication

·  Authorization

·  Configuration Management

·  Sensitive Data

·  Session Management

·  Cryptography

·  Parameter Manipulation

·  Exception Management

·  Auditing and Logging

When one is in the design phase of the web application they need to consider the security policies and procedures their application will have. These policies and procedures will determine what the application can and cannot do, what they have access to, and may be based off of the companies security policies themselves. “Make sure you understand the network structure provided by your target environment and understand the baseline security requirements of the network in terms of filtering rules, port restrictions, supported protocols, and so on”[4] this will make it so from a developers point they know where they are starting from. In general one wants to implement the least amount of access as possible.

In order to make sure that one’s application is a secure web application it must be thought about and tested from the very beginning. Every member of the development team needs to be testing and thinking about security from the very start of the application’s design. It is best not to wait until the end of the software development and then decide to make it secure. If that is done it will not be as secure of an application and there will be many security flaws that could have been avoided had security been an essential part of the design in the first place. The development process depicted in Figure1 below shows one example of a software development life cycle that is designed to make the application secure. Notice how often security checks are performed throughout the process.

Figure 1: A picture of the Software Development process

Input Validation

One key process to think about is how to validate the input that is given to the application. The general rule of thumb is to start by assuming all input is bad. Developers never want to allow input into their application to go unchecked. To start one wants to centralize their approach by making validation be a core element of how information is passed throughout their application. Some ways of doing this are to have some common validation strategies that go across the application and can be used to validate input from multiple places. Then develop more specific validation procedures as needed. For example if the user needs to enter a zip code it should only be a five digit positive integer that is entered. By doing this it can help stop hidden commands be passed along. Another general rule is, do not rely on client side to validate the clients input. An attacker could bypass the user’s client or shut off any scripts that are being used to validate input [4]. This makes it slightly more difficult by having the server do all of the validation and then passing the information back to the client but it is a lot more secure.

Here is one specific strategy for validation, called constrain, reject, and sanitize input.

Constraining input is only allowing certain data by validating the type, format, length, and range of the input. As a developer one needs to create a filter that checks the input against the validation rules [4]. Next one wants to reject known bad data. What is bad data? Bad data is any input that is known to be malicious or follows known malicious patterns of attack. The problem with known bad data is a matter of context. In certain scenarios one input could be fine and in another scenario the same input could be bad. Lastly sanitize the input that is received. This could be as simple as stripping a null character off the end or using “URL encoding or HTML encoding to wrap data and treat it as literal text rather than executable script” [4].

Authentication

Authentication refers to determining who a user of the application is. First identify where authentication is needed. For example when using an online time logging program, the user needs to sign in to use the application, this is a form of authentication. The time logging program needs to be able to see that the user is valid and has the correct password. The application must also be able to track that the user has been authenticated across the application. For example, when a user navigates from the time log page and then click reports page to view a summary of all the time logged. This requires some form of authentication token, most of the time in the form of a cookie.

Next here are some good practices to keep in mind to help improve security and authentication. First separate public and private areas of the web application. By separating when it is needed to authenticate and not authenticate the developer can create separate rules for different parts of the site. This can help avoid unnecessary performance issues that may occur due to having too much authentication. Next have account lockout policies for every account. Make it so they have to get in contact with someone or follow some procedure to get their password for the account. By locking out a user after a certain number of failed attempts it helps stop hackers using a brute force method of attack as well as stop denial of service attacks on the application. Next have the ability to disable user accounts. So if they have been inactive or an administrator has noticed some suspicious activity, the administrator can deny them access. Another useful tool is having password expiration periods. Such as UW-Platteville does where every ninety days the user has to change their password to something that they have never used before. Have the application require “Strong” passwords. This makes it harder for hackers to guess the password. For example have the password be required to have a capital letter, at least one number and be at least eight characters long (just one example). This makes it so there are more variations to a password and if an attacker were to try to use brute force, it would take a very long time to systematically go through all of the combinations to find the correct password. Also when it comes to sending passwords never send it over a network in plaintext. If someone is listening they could steal the password. Make sure to use SSL to encrypt the traffic. Lastly one needs to encrypt the authentication cookies that the application uses so that they cannot be stolen, such as the information that is contained in them, or copied, or modified for a malicious user to use. Another form of defense for authentication cookies is to have timeouts for them. So they are only valid for a certain amount of time and when that time expires another can be sent once the user is re authenticated.

Authorization

Authorization is very similar to authentication except authorization has more to do with determining where the user is allowed whereas authentication is who the user is. For authorization some features to implement into the web application are gatekeepers. Gatekeepers are on the server side and use IP Security Protocol to limit server to server communication and host restrictions. Next restrict what system level resources users can use or have access to. For example, files, registry keys, or what databases they can access. As a developer one wants to make sure they do not allow access to users who do not have permission to access it.

There are three models to consider when using authorization granularity. The first is impersonation; this allows resources to be accessed based on the security context of the caller [4]. This allows the user to have access across the system which is also the greatest weakness of this model. The trusted server model groups users together for their access privileges and is the most scalable because it can have multiple “roles” (user privileges). This allows all users in a certain role to have access to a certain elements in the server. The downfall of this is that it is not on a per user basis, meaning that one cannot have one user have slightly more or less privileges without putting him or her in a different role. The last is a hybrid of the two. This model is similar to the trusted server model in that it has roles that determine user’s access. The advantage of this model is that permissions can be set to separate users. The downside is that this method is contradicts the principle of having the system be least privileged. This is because this model creates multiple threads and that requires privileged access for some accounts. An example of this model is shown in Figure 2 below.

Figure 2: This shows the hybrid granularity model.

Configuration Management

The configuration management of the web application is the interface that allows the administrator/privileged user to change user permissions, web page content, database connections and profile information [4]. If a malicious hacker gains control over the web applications configuration management interface they would have access to the entire web application.

The first thing that is needed is to secure the administration interfaces of the web application. Have only authorized administrators be able to access it. This does not mean that all administrators can necessarily access it. As a designer one can have multiple layers of administrators so it is less likely that a malicious hacker can gain full control of the application. This comes back to having strong authentication procedure in the web application. Also make sure that the system is using SSL to encrypt and secure communications between the administrator and the server. [1] Next one wants to secure the applications configuration store. These are the configuration files, registry, databases, and any other sensitive information. Do not have any of these accessible from the web on the client side and do not make any calls or have anything hardcoded in the html file that could link back to one of these files or databases. Lastly as I said before use a least privileged process when assigning account permissions. Don’t let users have more access than they need. Also set up service accounts that handle the processes of the web application and can be given permissions. Set these up as least privileged so if they are taken control of they do not have access to everything [5].

Sensitive Data

Sensitive data is all of the personal information that users enter when they use the web application. These can be names, addresses, credit card numbers or any multitude of sensitive information that developers have a responsibility to make sure it is secure so it cannot be stolen or altered by a malicious user.

When dealing with sensitive data there are some practices that can be implemented to help avoid this problem. The first is not storing secrets, secrets are anything that needs to be kept private so a malicious user cannot have or be able to access easily. For example passwords, when a user signs in on a website they enter their password and the website has to verify that it is the correct password for them. The application does not actually need to save their password. After all it just needs to authenticate them. So one way to do that without storing the password is to create a hash of the password, so when the user signs in it compares the hash of the password to the hash the password that is stored. [4] This means that the database does not actually know the users password and if the database is accessed in some other malicious manor the user’s password is not necessarily stolen. Other practices are more common sense such as never store secrets in code. Never hard code anything that the users may have access to. Next always encrypt any and all secrets, whether it is database connections, passwords, or keys.

Sensitive User Data

This goes into a little bit more of an explanation of what should be done with all of the sensitive user data that the system has and how to send it. First of all, only retrieve data on demand not all at once. If the data is held in memory it is more accessible to attack, so only take what is need and go back for more if necessary. Next always send data over an encrypted channel (SSL). This is so it cannot be stolen en-transit from client to server or vice versa. Never store sensitive data in cookies as well. Do not do this for two reasons. One cookies can expire, and if there is key information in there, the system cannot decrypt it if is expired as well as the key to decrypt the cookie stays in use. Second the end user can modify unencrypted data in the cookie. This could be used to bypass the systems authentication.