Security Patterns in Web Applications

Lauri Kiiski Helsinki University of Technology lauri.kiiski@hut.fi

Abstract
A security pattern is a generic solution to a recurring security problem. Security patterns help developers and designers to design and implement secure systems and avoid common mistakes. This paper presents categories on security patterns in web applications and two patterns in detail. Also, this paper takes a look at implementation of these two patterns in two open source web applications. KEYWORDS: Security pattern, Web application, Java, JEE, PHP, Liferay, Joomla.

Introduction

Security has become an important part of every application today. Security is especially important in applications connected to the Internet. Web applications are such applications and lots of attacks try to exploit vulnerabilities in web applications. There are many common vulnerabilities in web applications, such as lack of input validation and to trust the data sent by the client. Web applications might also expose sensitive information when every access to page is not authorized or the account is compromised. Security patterns provide generic solutions to these and many other recurring security problems.

pattern might require to implement several other security patterns which solve sub-problems. To design a secure system, developer has to implement many of the security patterns and select between them reasonable. Security patterns help to design and implement secure software. Security patterns are written for humans and as such they are not something that machines can understand and utilize. They try to capture some of the experience and solutions to common problems. Security patterns present this essential information in a form familiar to software developers. The presentation of a security pattern is divided to different subtopics and there exists many variations. In this paper the security patterns have the following subtitles: abstract, problem, solution, issues, examples, trade-offs and related patterns. The described pattern template is the one used in Security Patterns Repository Version 1.0[4].

2.1

Categories of Security Patterns

Security patterns depend on each other. Security patterns in a same category relate to each other or those can be alternatives to each other. This section summarizes different categories of security patterns with the focus on web applications. The categories and patterns are based on Security Patterns: Integrating Security and Systems Engineering[5] with addition of patterns described in Security Patterns Repository Version 1.0[4]. 2.1.1 Identication & Authentication

Security Patterns

A security pattern is a generic and widely-used solution to a recurring security problem. A security pattern describes a common problem in a context and a generic solution to that problem. The solution describes the structure of elements and also the process to solve the problem. Security patterns are as technology independent as possible and therefore you can take advantage of the same patterns in different scenarios. A security pattern has been applied successfully describes an optimal working solution to the problem. In addition to the problem and the solution described, a security pattern points out the benets and drawbacks and also discusses about related patterns. A security pattern description usually provides references and examples. A Developer must understand the context and what he/she is securing when he/she is going to apply a security pattern. Security patterns depend on the context. Most security patterns depend also on each other. A solution to one security

Almost every web application have users which need to be identied and authenticated (I&A). The I&A Requirements is a pattern which provides common generic requirements for all identication and authentication services. It helps to determine what other Identication and Authentication patterns are needed in this specic application and context at hand. The I&A Design Alternatives helps to select one or many of the alternatives as an I&A strategy to satisfy the I&A requirements. The alternatives are Automated I&A Design Alternatives, the Physical I&A and Procedural I&A. All of the alternative patterns help to select suitable techniques and design appropriate mechanisms. The Automated I&A Design Alternatives considers techniques such as passwords, biometrics and hardware tokens which are implemented in software. Also Physical and Procedural I&A are choices in some situations. Those include measures such as a person verifying ID card. Password with username is the most common authentication method. The Password Authentication pattern describes

TKK T-110.5290 Seminar on Network Security how to design, create, manage and use password components and passwords securely. It also helps users to select nontrivial passwords and to handle passwords. For example, automated password-guessing attacks can succeed if passwords are weak and the system cant identify and react to those attacks. The Account Lockout pattern protects user accounts from automated password-guessing attacks and the system needs to disallow further attempts after too many failures. The Biometrics Design Alternatives pattern helps to select the correct alternatives for biometric mechanisms to satisfy the requirements. There are many biometrics mechanisms available such as face recognition, nger image, hand geometry, iris recognition, retinal scanning, signature verication and speaker verication. There are many types of hardware token mechanisms available. The Hardware Token Design Alternatives describes different alternatives and their trade-offs to help selecting the best for the current situation to identify the user. Some of the mechanisms are magnetic card and PIN, onetime password token in conjunction with user ID and using smart card. The Unregistered Users I&A Requirements pattern helps to dene requirements when there is no pre-registration. When pre-registration is not used, users can be identied and authenticated based on some public and private information such as name and social security number. 2.1.2 Access Control Model

2007-10-11/12 the correct functionality and the properties of the access control security service. The Single Access Point provides only one point of access to the system. This pattern simplies the protection of the system against misuse. The access point checks the client and either allows or denies the access as needed. When a single access point is in place, the Check Point can be used as means of I&A to respond to break-in attempts. The Authenticated Session pattern describes the use of a session for user authentication. The system creates the authenticated session after successful login and allows the user to access different pages of a single site without need to authenticate on every page request. Different users can have different rights on a system. There are two patterns to implement the access rights on the user interface. First, in the Full Access with Errors, the user interface exposes all functionality to the user but attempt to use an unauthorized functionality results to an error. Second, in the Limited Access, the user interface exposes only the allowed functionality to the user and the user interface looks different to users with different privileges.

2.1.4

Accounting

The security patterns in Access Control Model category represent security policies at high-level. They require several other lower level security patterns in implementation. The Authorization pattern describes who is allowed to access different resources and how, since most systems constrain access to resources. The Role-Based Access Control describes how to assign these rights to resources depending on the role of the user. This way, the administrators have to manage only a reasonable number of rights for different roles and not for every user separately. In some environments, sensitive information needs to be categorized and protected. The Multilevel Security describes how to categorize sensitive information and how to classify the data. It also describes how to categorize different organizational units and classify users. Users are not allowed to violate the access policies. Only trusted processes are allowed to violate the policies to change the classications. The Reference Monitor pattern describes how to use reference monitor to enforce access rights to resources. An entity requests resources from reference monitor which checks the authorization. The Role Rights Denition provides systematic approach to implement the least privilege policy based on roles of the users. Implementing the least privilege policy means assigning only minimal rights. 2.1.3 System Access Control Architecture

The access control security service is an essential service in an application where access to perform an action is explicitly permitted or denied. The Access Control Requirements is a pattern which provides generic requirements and describes

When security events occur, they need human attention. People responsible of the system need to know about security events. Security audit and accounting addresses this need by tracking the security events. The Security Accounting Requirements pattern provides generic requirements. The Security Accounting Design pattern helps to design accounting to meet the requirements and to select the services and functions to support the accountability. Auditing is a process to analyze logs or other information of an event. The Audit Requirements describes the requirements and the Audit Design helps to satisfy these requirements. In addition to that, the Audit Design also helps to identify the logging requirements. Logged information can be used to reconstruct events and to analyze the problems. The Audit Trails & Logging Requirements pattern provides requirements for the analysis. The Audit Trails & Logging Design pattern helps to design an audit trail and logging mechanism. Intrusion detection automates the detection of security events in critical parts of the system and it responds quickly to security events. Intrusion Detection Requirements helps to capture the requirements to design an intrusion detection service with the help of the Intrusion Detection Design pattern. The Secure Assertion pattern maps assertions in a software to systems intrusion detection system (IDS). This allows the IDS to detect problems in the software which can be a result of attempted misuse. Non-repudiation creates links between events and actors. Its purpose is to provide the facts that someone did something so that parties cannot deny what they did. The NonRepudiation Requirements pattern provides the requirements and the Non-Repudiation Design pattern provides the guidance to implement a non-repudiation mechanism.

TKK T-110.5290 Seminar on Network Security 2.1.5 Secure Internet Applications

2007-10-11/12

Sensitive information can be protected with the help of the Information Obscurity pattern. Usually is achieved by encrypting the data and obscuring information about the environment. The Client Data Storage pattern uses encryption to store data on the client. This avoids problems where client could modify, for example, cookies, hidden elds or URL parameters. The Encrypted Storage pattern provides help to encrypt data on servers disk. The Hidden Implementation pattern hides the internal workings of an application making it harder for an attacker compromise the system. The Secure Channels pattern describes how to protect communication across public network. The use of secure channel is essential when trasferring sensitive information. If the interactions with user and service are sensitive or of high value, the correct identity of the parties is critical. The Known Partners pattern describes how the identities can be identied uniquely. In web application forms, client can input any data it wants. Some of the data can be harmful and should not be accepted. The Client Input Filters pattern describes what measures should be taken to protect the application. Web servers are subject to attacks. Demilitarized Zone is a solution to separate all other systems, such as databases, but the web servers from direct public access. In addition to packet lter rewall, the web server can be protected with the application level Protection Reverse Proxy. When there are many applications from different hosts which compose the web site, the Integration Reverse Proxy helps to hide the physical distribution of the individual machines. The Front Door pattern provides a single login and session for multiple services. An ideal point to implement the front door is on a reverse proxy.

Most organizations have different groups of job descriptions. These groups have different responsibilities and permissions to resources. We can use this classication to enforce access control to resources. These groups can be interpreted as roles like employees, customers and partners. Users are members of roles and roles have the correct access rights. When administrator creates new user accounts, he/she associates those accounts to the correct roles. Also, he/she can create new roles with new access rights as needed. One user account can have many roles if needed. Issues The solution might not be exible enough if it is not possible to create new roles and include one account in different roles. This could require a person with different roles to have multiple accounts, one for each role. Examples In a web application there can be, for example, administrator accounts, editor accounts and registered users. Administrators can modify everything, while editors can only publish new articles. Registered users are allowed to view all public information and also the pages restricted to registered users. These roles make it easy to assign rights to new users. Trade-Offs The pattern simplies the administration of access control because access rights are assigned only to couple of roles and not to every user individually. Adding, removing and modifying users and their rights is easy because there are already suitable roles with correct access rights and it is only required to assign a role for a user. If multiple roles are allowed, it is also possible to make rules that users in specic role cannot have access to some other roles resources. In very simple cases roles introduce unnecessary complexity. Assigning users to multiple roles with conicting access rights is problematic. It might be challenging to identify the different roles and assign correct rights for roles.

2.2

Essential Web Application Security Patterns

This section describes two security patterns for web applications. First we describe Role-Based Access Control[5] and second Client Input Filters[4]. 2.2.1 Role-Based Access Control

Abstract The Role-Based Access Control describes how to assign rights to resources depending on the role of the user in an environment where there are large numbers of users and resources which need access control. Problem

In an environment where there is large number of users and resources which need access control, assigning individual Related Patterns access rights is not feasible. It would require too much work and it is hard to keep track of the rights manually. We need Authorization - Users are authorized based on roles. a convenient way to administer the large amount of access rights. Multilevel Security - Roles can extend multilevel security. Solution

TKK T-110.5290 Seminar on Network Security 2.2.2 Client Input Filters

2007-10-11/12 Many websites store information at the client in cookies, hidden form elds or as URL parameters. The underlying web framework might not have other way to maintain the state. However it is more secure to store this information encrypted at the client since attacker can view this information and modify it. For example, plain text passwords should never be stored at client. Accounts, which try to forge the data, should be locked. The user should be contacted out-of-band or wait for the user to contact the administrator. It is possible that the user account has been compromised. There are many tools available to inspect all the content of the website including the hidden content. Every web browser has an option to view the source of the page and there are several easy to use plugins which can show the source and active components on the page and allow to modify the page at runtime. When the application identies suspicious behavior, it should log the event. These logs can be analyzed later to correct possible damages, used for prosecution and integrated into Intrusion Detection System to inform system administrators automatically. Even if client uses JavaScript to validate form submissions, the application needs to validate the input also on the server. It is trivial for a client to disable JavaScript and bypass the checks. In addition to that, all calculated values, such as a total price of a shopping cart, must me calculated again on the server, since the client can modify the values before submission. If an unauthenticated client can request a transaction, the submission should be sent to a sanity-checking module before the transaction is processed. The sanity-checking module checks, for example, the validity of all elds, random garbage submitted and suspicious elds. If the website allows to submit input, it should be ltered carefully. Submission should have reasonable maximum length and special non-printable characters should not be allowed to prevent buffer overows. All program code and tags should be removed when they are not explicitly allowed to avoid cross-site scripting. For example, HTML formatting might be allowed but the site should allow only limited set of tags for formatting. There are libraries for ltering and developers should use them. Cross-site scripting attack occurs when the web browser executes the user submitted scripting as part of the page. The web application should be secured to protect against password-guessing attacks. The Account Lockout pattern helps to protect against password-guessing attacks. Also, resource consumption is one possible attack. In resource consumption attack, the attacker tries to consume maximum amount of some innite resource. Examples Client Input Filters is used commonly in web applications. User registration forms validate the input and mandatory elds. For example, sites accept only valid e-mail addresses in addition to sending a conrmation e-mail. Web shops like Amazon.com store all shopping cart

a.k.a Intercepting Validator, Untrusted Client, Server-Side Validation, Sanity Checking Abstract Web application client can input any data it wants. Some of the data can be harmful and should not be accepted. The Client Input Filters pattern describes what measures should be taken to protect the application in this case. Problem Web applications are client-server applications where clients cannot be typically trusted. For example, web browsers are usually working as expected but might be compromised with functionality to modify the page. That said, servers cannot control what happens on the client side but too often they trust the client. Sites might rely on sending hidden form elds where data from earlier pages is stored or some calculated values like a sum in a shopping cart. However, this data cannot be trusted, since it is trivial for a client to alter this data before sending it back to the server. For example, a client could modify a precalculated price in a web shop. Client-side validation of form in JavaScript can be interactive and helpful for the user, but this validation is not enough. Attacker can disable JavaScript and inspect what kind of validation that script does. Attacker can use information about the validation further to make a successful attack because the script might reveal something about the security of web applications. One problem is also that web applications allow submission of free form text. This text can be some harmful code which tampers the database or is executed when it is viewed as a part of a page. Solution All data submitted by a client should be handled as untrusted and suspected. It is critical to identify the submitted data. It is not only the visible form elds but it is also the hidden elds, URL parameters and client side cookies. All data must be ltered and validated at the server before the data is processed. All calculated elds must be calculated again since client could have modied the value. If data needs to be stored on a client, it should be encrypted to avoid tampering. In addition to validating input, the server should look for signs of attacks and deny and log them. The server should strip all content which are not allowed like HTML tags, JavaScript code and SQL clauses. It is a better approach to implement validation in separate objects rather than integrated into web page because it is easier to implement correctly and the solution is reusable. If the validation fails, site can notify the user. Suspected attacks should be denied and reported. Issues

TKK T-110.5290 Seminar on Network Security

2007-10-11/12

information at the server and clients have only session are also unregistered users who have access only to public identiers. This effectively prevents clients to modify the parts of the site. data. Four of the user groups have access only to the Site Frontend and the other three have access also to the Administrator Trade-Offs Back-end. The Site Front-end user groups are Registered, Author, Editor and Publisher. Registered users have only If the lter is too sensitive, it might deny legitimate permissions to view pages but the other groups have permisusers. That could increase the work load on customer sions to edit, delete and publish the content on page. Author service and administrators analyzing false positives. can edit documents, Editor can also edit and create new documents and Publisher can also publish them. The lters incur some performance penalty because of User groups of the Administrator Back-end are Manager, the validation and possible encryption. Administrator, and Super Administrator. Manager has the This pattern helps to maintain data integrity of the web least privileges and the Super Administrator has the highest privileges. In addition to access to the back-end they all have site. all access to the Site Front-end. Only Super Administrator is allowed to modify other user accounts. Related Patterns Network Address Blacklist - Responds to suspicious 3.1.2 Implementation of Client Input Filters client action and can insert clients to network address blacklist. Joomla! has a set of functions to lter client input. They are well documented and API[1] is on the Joomla! website. If Account Lockout - Protects against password-guessing developers do not take care of input ltering, PHP applicaattacks by locking out an account. tions are vulnerable to many attacks. Creating a new account requires ltering the client input to 3 Security Patterns in Open Source prevent, for example, cross-site scripting and SQL injection. Joomla uses function JRequest::getVar() to fetch all form pasoftware rameters. It strips all HTML and PHP tags and slashes if needed. After the validation it, saves the new user account to This section inspects two open source web applications. First database. we inspect Joomla!1 Content Management System and secBefore saving information to database it must be escaped. ond Liferay Portal2 . This section explains how the presented Joomla provides here a function JDatabase::getEscaped(). security patterns are applied in these applications. Below is the source code for this simple function. Both Joomla! and Liferay are popular, widely adopted and awarded in their categories of web applications. They /** run on different platforms. While Joomla runs on a quite * Get a database escaped string lightweight platform consisting of PHP3 -capable web server * @return string and MySQL4 database, Liferay is a Java 2 Enterprise Edition */ web application which requires a Java application server in function getEscaped( $text ) addition to some database. { return mysql_real_escape_string 3.1 Joomla ( $text, $this->_resource ); } Joomla! is a Content Management System (CMS). It is a web application for building different kinds of web sites. You mysql_real_escape_string() is a function provided by can use Joomla! to build small personal web sites as well PHP. It escapes the string for input to MySQL database. as large and popular commercial web sites. Joomla is written in PHP and it uses MySQL as its Database Management System (DBMS). This paper looks at Joomla! 1.5 Release 3.2 Liferay Candidate 3. Liferay Portal is an enterprise portal solution and it has also built in CMS and collaboration suite. Developers can use 3.1.1 Implementation of Role-Based Access Control Liferay to build large intranet sites and public services. For The role-based access control implemented in Joomla! is example, it can manage documents and provide blogs, mail relatively simple. Joomla! has seven pre-dened user groups and calendar for users. This paper looks at the latest stable for registered users and every user is in one of the groups. It version of Liferay which is 4.3. is not possible for user to be in more than one group. Every user in a group inherits the permissions of the group. There 3.2.1 Implementation of Role-Based Access Control
http://www.joomla.org http://www.liferay.com 3 PHP http://www.php.net 4 MySQL http://www.mysql.com
2 Liferay 1 Joomla!

Liferay implements very exible role-based access control. The article Liferay: Permissioning Explained[3] explains the permissions system in Liferay.

TKK T-110.5290 Seminar on Network Security Every User belongs to one Location and one Organization and it inherits permissions and roles of a Location and Organization. In addition, a user can belong to a UserGroup from where it also inherits permissions and roles. A user can also belong to a Community. Users permissions can be inherited or assigned directly to a specic Resource. A Role is a collection of permissions and a User has Roles. A Resource is any object in Liferay like a portlet or a blog entry. Administrators can assign permissions to Resources. Communities, Organizations, Locations and UserGroups have permissions and a role. Users inherit permissions if they are included in any of those. Communities are above Organizations, Locations and UserGroups. It means that permissions are inherited from Communities to Users if Organization, Location or UserGroup is part of a Community. 3.2.2 Implementation of Client Input Filters

2007-10-11/12 We presented the different categories of security patterns and we presented two patterns in detail. The presented patterns are Role-Based Access Control and Client Input Filters. Validating input is critical for web applications, since for example cross-site scripting attacks are very common and harmful. It is challenging to implement and administer access control of authenticated users when there are lots of users and many resources requiring access control. Both Joomla! and Liferay implement Role-Based Access Control and Client Input Filters patterns. Both of them validate the user input and strip any suspicious content with helper functions before saving new user accounts to the system. This is implemented quite similarly in both of them. Their implementation of Role-Based Access Control on the other hand is very different. While Liferay has very negrained groups of roles, Joomla! has pre-dened roles with pre-dened permissions.

Unfortunately Liferays source code is not very well documented. Javadocs[2] are provided but they are probably gen- [1] Joomla! 1.5 API Reference, 29.10.2007. http: erated from java les, since they do not contain any explana//api.joomla.org/li_Joomla-Framework. tions in there. html. When administrator creates new accounts to Liferay, the JSP page creates an instance of ContactImpl. ContactImpl [2] Liferay Javadocs API, 4.11.2007. http://www. liferay.com/web/guest/documentation/ extends ContactModelImpl which uses XSSUtil to validate 4_3/development/api. the input. The validator checks the input with regular expressions and strips tags. Below is a source code for method ConPermissioning Explained, 4.11.2007. tactModelImpl.setUserName(). Other setters in this class are [3] Liferay: http://wiki.liferay.com/index.php/ implemented similarly. Permissioning_Explained. public void setUserName( String userName) { if (((userName == null) && (_userName != null)) || ((userName != null) && (_userName == null)) || ((userName != null) && (_userName != null) && !userName.equals(_userName))) { if (!XSS_ALLOW_USERNAME) { userName = XSSUtil.strip(userName); } _userName = userName; } } [4] Darrell M. Kienzle, Matthew C. Elder, David Tyree, James Edwards-Hewitt. Security Patterns Repository Version 1.0. 2002. http: //www.securitypatterns.com. [5] Markus Schumacher, Eduardo Fernandez-Buglioni, Duane Hybertson, Frank Buschmann, Peter Sommerlad. Security Patterns: Integrating Security and Systems Engineering. John Wiley and Sons Ltd, 1st edition, 2005.

References

Conclusion

The security patterns are for developers and they help address security problems and avoid common pitfalls. This paper focused on security patterns in web applications. A handful of security patterns should be applied in web applications because attackers and automated attacks try to break in to systems. Every developer in a web application project should know at least what patterns exist and where they apply.