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. 2

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. 3

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. 4

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. 5

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 6 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.

Session Management

Web applications are built on HTTP which is stateless. So the application must handle sessions so they can in a way treat the application as a state. They do this to increase security. One method to help with session management is to use SSL to encrypt session authentication cookies. Make sure to create a setting that tells the browser to send these cookies back to the server and not to the user. Encrypt the contents of the cookies. Like before, this stops attackers using cross site scripting attacks from modifying the cookies. If the cookie is stolen the attacker would be kicked out after the cookie expires. Have a limit on the session lifetime. Similar to banking websites where after a certain amount of time it makes the user log back in before it the user is allowed to do anything else. Lastly protect the session state from unauthorized access. So make sure the application uses SSL to secure the link from the web application to the location that is storing the session state.

Cryptography

Cryptography provides privacy, authenticity, integrity, and authentication for the web application. Each of these three aspects helps to make the web application more secure. Privacy is keeping the data or secrets safe and confidential from those who are not authorized to view or edit that information. Authenticity means that a user cannot deny sending a message to the server, such as a cookie of some sort. Integrity means that when cryptography is in use the application knows that the data that is being sent has not been altered in any way. Authentication is much more straight forward. Authentication is simply determining who the sender of the message is. [4] The application does not want to accept messages from sources that are not valid, like a malicious hacker.

Here are some guidelines on cryptography so that when implemented, it can be the most effective. First never develop cryptography unless there is a trained expert on the development team. Cryptography algorithms are extremely difficult to create and have them be successful. If developer creates their own encryption and it has not been adequately tested there may be unforeseen vulnerabilities. Instead use algorithms that have been heavily tested to work. Next do not grab data to encrypt or decrypt before the system is ready to do it. This is so the system does not have data sitting in memory waiting to be used. [4]

When choosing an algorithm know what and where it will be used. Some algorithms are better for certain jobs or requirements. For example DES (Data Encryption Standard) is good for data that is only stored for a short time. It is fast but not as strong as some algorithms. Unfortunately when it comes to cryptography speed affects the strength of the algorithm. An example for encrypting large amounts of data to be stored for a longer period of time would be to use Rijndael. Use this if data needs to be stored for longer periods and is not accessed on a regular 7 basis. It is slower but stronger than DES. What it comes down to is what the job that needs to be done is and what constraints does that job have. Also when considering what algorithm that will be used, one needs to take into account the key size that will be used. The larger the key size the more secure the data is. Once again it comes down to what the encryption is needed for. Lastly once a key size is picked, one must also consider how to keep the key secure. One suggestion is to rotate the keys. For example, if there are fifty keys only one of them is active at a time. Occasionally replace the key with a new key so that the same key is not being used all the time. This makes it so it is less likely that someone will be able to decipher what the key is. [4]

Parameter Manipulation

Parameter manipulation is when “the attacker modifies the data sent between the client and Web application” [4]. This data is sent from any of the input fields on the screen he user is using such as HTTP headers or form fields. Things that can be sent are query strings, JavaScript, and cookies. So once again in order to keep the system safe from attack use the method discussed earlier, “constrain, reject, and sanitize input.” First make sure that any sensitive cookies that the server side uses are encrypted. Make sure to use cryptology techniques discussed earlier. Next do not let users to bypass the security checks that have been put into place. For instance changing the URL on some websites allows the user to access certain files or web pages that normally a user is not allowed to go because they are not authorized. For example if null bytes are injected into the URL data can be retrieved from the server such as the index file. Make sure to check the URLs on the server side and not on the client side using java script that can be disabled. Validate all values received from the client. Make sure that the values entered are the only ones that the system allows. Lastly never trust HTTP header information. The web application should not base security off of HTTP requests. These can be modified by the attacker. [4]

Exception Management

DOS attacks are where a web page is attacked to the point that the server cannot handle the traffic it is retrieving and forces the web page or system to crash. Good exception handling can help prevent DOS (denial of service) attacks and can help stop system information from being leaked [4]. Never leak information to the client, for example when debugging. Sometimes programmers output stack traces. These show programmers exactly where the error occurred and what function was called to get there. This is a major vulnerability however if left for the user to see. So instead, the exception handler should give the user some sort of generic error message and not a stack trace or any other vulnerable information. Next log error messages for an administrator to review. The administrator and developers need to know where, when and how an error occurred. An error could occur due to vulnerabilities in the system and the administrator needs to know about it so it can be fixed. Lastly always catch all exceptions that the system throws. This “avoids leaving your application in an inconsistent state that may lead to information disclosure” [4] or vulnerable to DOS attacks. 8

Auditing and Logging

When developing the web application, it is important to incorporate logging features into the different aspects of the application. This should be done so that an administrator can use the logs to detect suspicious activity such as a low privileged user accessing a higher privileged feature. The administrator can then disable that account or purse any other action that they see fit. By logging everything the admin could also potentially find out how they infiltrated the system and its security measures.

First, consider the caller identity flow across the application. The caller identity flow is how functions and data are accessed as well as the connections between different aspects of the application. This will determine what kind of auditing that can be done. OS level auditing can limit the scope because if the database cannot be stuck on a middle level. Otherwise the auditing can be done on the application level but then one has to make sure that they trust the middle level of the application. Next, as discussed earlier, key events such as failed logon attempts, modification of data, or administrative functions and others need to be logged for review. Since these events are being logged, the log file must be stored somewhere. So the log file needs to be encrypted and restrict access to them as much as possible so attackers cannot cover their tracks. Lastly back up and analyze the log files regularly. Log files do not do any good if they are never reviewed. Do not store the back up on the web server as well for security. This is so that these logs cannot be altered to hide attacks that have happened in the past and they are backups to the ones that are on the web server. [4] So if the web server crashes you still have some log files if not the current ones. One program that can be used for logging is BIG-IP ASM. This program provides a graphical interface along with some neat features. This program not only tracks reports, but provides a visual interface to the attacks that the system receives as well as any attack patterns that occur. It can also tell the location of the attack and help detect brute force attacks. [3] In all logging is a very important feature that all applications should have so that bugs and attacks can be detected and tracked.

Summary

The core concept of web security is thinking about it from the very beginning. Every aspect of the application should have security designed into its framework. Never accept anything as good input, always check the input. Authenticate and authorize users so that not everyone has permission to access every aspect of the web application. Have some place to change rules and permissions in a management interface. Protect any and all sensitive data – it is sensitive for a reason and should be protected for the developers own protection and that of the users. Make sure to have a way to track sessions and have timeout times for every session. Double check input and once again and do not let users manipulate the input fields. Always handle exceptions and never show them to the user, give generic messages instead. Lastly always log and make sure to check the log files. There is no point in having log files if someone never checks them. The best way to create secure web applications is to have good designs that 9 incorporate security into them from the start and to be thinking of vulnerabilities as it is developed and how to solve them.

References

[1]Chandwani, N. (2010, November 6). Building a robust web application security plan. Retrieved from http://www.mcafee.com/us/resources/white-papers/foundstone/wp- building-robust-web-app-sec-plan.pdf [2]kolodgy, C. J. (2011, February). The case for building in web application security from the start. Retrieved from http://resources.idgenterprise.com/original/AST- 0048510_The_case_for_building_in_web_application_security_from_the_start.PDF [3]MacVittie, L. (2009). Manageable application security. Retrieved from http://www.f5.com/pdf/white-papers/manageable-application-security-wp.pdf [4]Meier, J. D., Mackman, A., Dunner, M., Vasireddy, S., Escamilla, R., & Murukan, A. (2003, june). Design guidelines for secure web applications. Retrieved from http://msdn.microsoft.com/en-us/library/ff648647.aspx [5]Microsoft. (2012). Basic security practices for web applications. Retrieved from http://msdn.microsoft.com/en-us/library/zdh19h94(v=vs.100).ASPX

Acknowledgements

Gabriella LeFevre, Brian Majerus, and Sean M. Kenefick for help with the editing.