A Meta-Language for Web Application Profiles - jwall.org

A Meta-Language for Web Application Profiles Christian Bockermann, [email protected] Revision : 9 April 5, 2007

Usage of the mod security[4] advances to more and more complex rulesets that often aim at a positive security model for a specific web application. Since the mod security rule language is located at the level of an assembly style language the development of positive rulesets is tedious and error-prone. This article proposes a XML-based meta-language1 which provides a highlevel language for writing positive application rulesets.

With the growing number of applications being accessable over the web, the number of attacks performed against web servers and their applications has grown along. Most of these attacks aim on the applications vulnerabilities at the application logic level and can thus not be prevented by traditional network-based firewalls. To overcome this issue security vendors are starting to develop application-layer firewalls2 which are acting as reverseproxy in front of the web server. An open-source approach to this is the mod security-Module by Ivan Ristic. It is a filter module for the popular Apache webserver that offers the possibility of filtering HTTP requests sent by a web client with respect to all of the requests properties.

rulesets. Unfortunately neither of these seem to have found a broad acceptance/distribution. This work is inspired by both of these efforts and a longtime use of the mod security module to protect web applications and aims at a more generic description of profiles as is possible with the use of the rule-language of mod security. It proposes a new highlevel language based on XML to define application profiles that can later be transformed into filter rules for the mod security module. The approach used in this work starts with the mod security rule-language and tries to find a level of abstraction without loosing to much flexibility. The paper is structured as follows - section 2 gives an overview of the design goals I tried to take care of during development of the language. Section 3 defines the basic web environment that the language covers and several terms and definitions used throughout the rest of the paper. Following these basics, section 4 contains the description of the meta-language. For practical use section 5 provides examples on how profiles written in the meta-language can be transformed into a ruleset usable within mod security.

1 Web Application Profiles and Related Work Unfortunately most of the filtering approaches are based on a negative security model that specifies attack patterns and blocking requests that are classified as anomalous by these patterns. This helps preventing most of the known attacks, but is still vulnerable to day-zero attacks. A more secure approach follows the philosophy of traditional firewall systems and specifies an application specific ruleset based on a positive security model of that application. This defines the applications resources and specifies all the legal accesses on the application level. These rulesets are in the following called application profiles or just profiles. There have been efforts to specify such profiles in [6], which proposes a policy definition language for a whole security gateway, whereas [5] is a work of mod security author Ivan Ristic propagating a portable format for web application

2 Goals of the Meta-Language The basic mod security rule-language represents a flexible and powerful language that allows a complete specification of the HTTP communication between a client and a webserver. In addition to that it provides a big set of actions that one can set to be taken in case some conditions defined by rules of a set are violated. The meta-language presented in this paper aims at easy creation of web application profiles observing several additional features.

1

The use of the word language might be misleading here. It is more a scheme for specifying web application rulesets. However I will stick to the somewhat incorrect term language in this document. 2 Since this area is still in movement there are several synonyms for these kind of systems, like application security gateway, application filter, etc.

Simplicity The main goal of the meta-language is to simplify the definition of a web application profile in a clean way without loosing the power of the basic rule-language. Be-

1

each of these requests as a transaction that is - following the stateless nature of HTTP - as indepedent of the other transactions of the user. Each of these transactions are sent to a resource of the application for further processing. These resources are identified by an unified resource locator or URL. The classic way of writing dynamic web pages have been HTML-based forms that contain input elements for user-data. This user-data is sent to resources such as scripts or programs identified by their URL. Data sent to these resources can be encoded within the query-string part of the URL or as part of a request-body in case of a POST-request3 . The approach of [3] considered an application as a single program identified by a single URL. This does not hold for modern web applications as most of these applications consist of several resources processing user-data in several requests of communication. Each of these steps can be seen as an individual transaction. With the identification of a resource with its URL we define a web application as a set of resources (or URLs) that are located under some common prefix-path (application context). This does include any static resources such as images or HTML pages as well as dynamic scripts, programs or servlets. This definition of an application is a basic assumption that the meta-language relies on.

sides that the profiles written in this meta-language should easily be convertable into the mod security rule-language by the use of XSLT-transformation. Being written as XML code makes the use of an XML-editor possible which may assist editing the profile. Portability The proposed language shall be as portable as possible to provide the most abstract way of specifying an applications profile. This way it should be possible to deploy a profile for an application regardless of the applications own context-path, i.e. the use of absolute references (for example when specifying paths) should be reduced to an minimum. Beyond this a possible conversion into web application filters others than mod security might be possible. This may also result in profiles written for other filters to be converted to mod security. Ruleset Performance The use of XML also aims at a possible optimization of rulesets when being transformed into a set of configuration directives as used by the apache webserver. An example XSLT-style for a basic (non-optimized) tranformation into the rule-language of mod security (version 2) is provided in the appendix of this document. The meta-langage shall be used to specify abstract profiles without requiring the user to think about optimization of the profile during the creation phase.

4 Meta-Language for Application-Profiles Automatic Generation As a lot of automatisation is used in building todays web applications (rapid developmenttools, HTML form-generation from XML-descriptions of data-models, XML-deployment descriptor used in the Java web containers, etc.) the use of XML assists a possible generation of profiles from other application descriptions. For example the struts-validation[2] might be a possible source for generating profiles. However, care needs to be taken here as this may also lead to vulnerabilities of an application caused by improper specifications implying wholes in the applications security profile.

4.1 Language Concept The basic concept of the language follows can be described as nested implications. Every element of a profile is an implicication - even the profile itself. The only exception to this is the Meta-Inf-element described below. You can think of an application profile as a set of limitations that imply conditions to the requests made to that application. The profile itself implies a set of such conditions expressed by its child-elements. This way you can create a base condition that implies additional limitations by nesting additional tags into the base condition as shown in figure 1. In this ab-

Extensibility As the meta-language is a proposal it tries to be as complete as possible. However it should provide the possibility to be easily enhanced without the loss of compatibility to profiles written with earlier versions of the language.

Figure 1: Nesting implications

3 Web Applications, Resources and Transactions

stract example the condition c2 needs to be fulfilled if c1 holds for a given request. As conditions can be marked optional of mandatory, nested implications can result in a more complex conditions that is the product of ANDing the base condition with all its child elements. Thus, if c1 is mandatory to a request it enforces a request to need to match both conditions, expressed in boolean notation: c1 ∧ c2.

This section defines several basic terms for describing web applications and their structure. As there is often no official agreement of what an application is and so most of these definitions are based on the rfc-articles/language-definitions mixed with the authors experience. Users (as well as programs) interact with web applications by sending requests to the web server that contains the application. The application itself is embedded into the server by some kind of runtime environment that provides an API to the application (often directly integrated into the language used by the environment) for easy access of the request and generation of appopriate output that is sent back to the client in a HTTP response message. We consider

Profile Root Element As with all XML-based languages the meta-language of this paper is hierarchically structured. The root of an application profile is specified by the Profiletag. All of the nested elements contained in this root-tag define the profile of the application. 3

2

Encoding can also be done in both ways during a POST-request when supported by the web applications runtime environment

To be more flexible the use of regular expressions is also possible when specifiying the location’s name. The value of name is not limited to anything which makes it also possible to write the above in one location-tag by using

The Profile-tag provides an attribute base which allows the specification of the context path of an application. Its intention is to make it possible to apply the profile to an application (e.g. a forum) wether it is located at http://forum.example.com or within the URL http://www.example.com/forum. The use of this attribute is optional as it defaults to an empty string, representing the root-node of an url.

However the first approach is more advisable as it is easier to read and much more flexible when it comes to transformation into “real” rulesets. It also specifies more atomic parts of the profile which might become an advantage when it comes to optimization of the profile.

Profile Meta-Information For information about the profile a Meta-Inf-section can be used that contains the author, version as well as a description of the profile (see figure 2). The declaration of such meta-information is optional and

Resource-specific Tags The resource-specific description follows the mod security approach of defining request requirements. This part of the meta-language consists of a set of tags each of which describes a different request property and can be seen as preconditions or conditions that a request to a resource has to fullfil. Additionally they provide different sets of attributes that are used to define limitations on these properties. Table 1 lists the currently available tags for describing an applications resources. Each of these tags covers an aspect of an incoming request. The Method-tag describes the method used when requesting a resource. The Header-tag provides limitations according to one (or more) of the fields in the request-header. The most fundamental for use in describing application resources is probably the Parameter-tag. It allows to define restrictions on the parameter passed to the resource in a request. Similar to this is the Cookie-tag which may be used to define the cookies/cookie-values that are allowed to be transmitted. All of the tags except Method-tag define a set of variables that can be checked or limited. For selection of a variable of the set associated to a tag they provide a name attribute which is used to select a variable of the set. This attribute can also hold a regular expression to limit several variables of the set. The attributes name and value

[email protected] 1.0 An example for introducing the proposed meta-language. ... Figure 2: Meta-information of a profile can be left out but it is generally a good idea. For specifying the application there are two basic groups of tags that a profile consists of: structural and resource-specific tags. Structural Description The applications structure is described by the use of the Location-tag which works similar to the corresponding directive in the apache configuration. An location defines a resource or set of resources and contains several resource-specific tags which specify these resource’s requirements. Thus the Location-tag serves as an element for describing the application’s structure on the one hand and as a container for the requirements on the other hand. Besides resource-specific tags the Location-tag can also hold nested locations forming a tree that resembles the application’s request-path tree. Figure 3 gives an example for specifying a profile for FormMail.pl. As you see in the above

...

Tag Method Header Parameter Cookie

Attributes value,regexp name,value,regexp,required name,value,regexp,scope,required name,value,regexp,required

Table 1: Tags describing request-properties

or regexp are mandatory for these implications (with the exception of Method, which has no name-attribute). The basic attribute name is used to specify the name of a specific property (i.e. the name of the parameter in case of a Parameter-tag or header-field in case of a Header-tag) of the properties defined by the tag. For the name-attribute the use of regular expression is also possible to restrict several specific properties. The use of one of the attributes value or regexp is mandatory as this defines the restriction on the properties selected by the tag and its name-attribute. The attribute value implies the check against a concrete value or a value defined by some other implication (see 6, Back-Reference for details). Alternatively the property can be limited by a regular expression given by the attribute regexp.

Figure 3: Profile of an application (structure) figure, the location-tag defines an attribute name which specifies the path element of the resource(s) defined by this tag.

3

...

Some of the conditions can also be specified as optional in which case the value of the corresponding requests property is checked against the condition only if the property is contained in the request, that is, the property does not have to be set in the request. Conditions are marked optional by setting their required attribute to false.



Parameter-Tag This tag defines restrictions on the parameters and parameter values which can be sent to a specific resource. The Parameter-tag supports an additional attribute scope. With this you can define wether the parameter you want to address resides in the header of the request, that is in the query-string, or in the body-part, i.e. the request payload. Of course you can define your implication to restrict a parameter in both scopes by setting the attribute to both. The default scope will observe both places if the parameter implication is not nested within a Method-tag. This will imply nested Parameter-tags to be associated with the scope defined by that method (header-scope for GET-requests, body/payload for POSTs). Thus in the following example parameter p1 is referring to a parameter called “p1” in the payload of the request. The second parameter-check is made against the parameter id as provided in the query-string of a POST-request.

Figure 4: Chained condition for a resource Figure 5: Expressing parameter-dependencies

5 Transformation to the mod security Rule-Language This section shows how profiles specified in the metalanguage can be transformed into directives of the mod security-module. A complete XSLT style for transformation is currently worked on. Since each of the tags defined in 4 associates a collection of request-properties, they can be directly mapped onto conditions that are checked by mod security rules. Keep in mind that the profiles describe a positive model of the application which leads to inversion of the defined regular expressions and matches against these to a blocking of the request. For example a Parameter tag of the form



may be translated into the following rules, where the first line is a result of the attribute required being defined as true implicitly.

Header-tag The Header-tag allows the definition of implications regarding the value or existence of one or more fields in the header of a request. The name attribute can be used to select the field(s) that is/are to be restricted. As with the Parameter-tag the selected field(s) can be checked against a value or a regexp by the use of the appopriate attribute.

SecRule &ARGS:p1 !^1$ "drop,auditlog" SecRule ARGS:p1 !\d+ "drop,auditlog" Another basic concept of the meta-language is its use of nested conditions as describe in section 4.1. This can be translated into mod security rules by the use of the skipaction provided by the target language. If the conditions implied by a tag fail, all nested checks are skipped. The example of figure 4 can be easily transformed into the following rules

Cookie-tag To define implications with respect to cookies the Cookie-tag can be used. Usage of this tag is similar to the Parameter-tag with the effect that it implies rules to check the existence/values of cookies.

SecRule REQUEST_URI !"script.pl" phase:2,skip:7 SecRule &ARGS:id !^1$ phase:2,drop,auditlog SecRule ARGS:id !^\d{32}$ phase:2,drop,auditlog

4.2 Examples

SecRule REQUEST_METHOD !"GET" phase:2,t:none, \ skip:4 SecRule &ARGS:p1 !^1$ phase:2,drop,auditlog SecRule ARGS:p1 !^\d+$ phase:2,drop,auditlog SecRule &ARGS:p2 !^1$ phase:2,drop,auditlog SecRule ARGS:p2 !^\w+$ phase:2,drop,auditlog

The following paragraph contains several examples for defining properties of requests using the proposed language. Figure 4 shows the tags needed to express a resource depending on an integer parameter p1 when accessed through a GETrequest whereas the integer parameter id has to consist of 32 digits and must be contained in any request sent to this resource. Additional prerequisits can even be stated to express the correlation of parameters such as existence of p1 requiring the presence of a parameter pi with a certain value by the means of

This also respects nested conditions on parameters as for example the dependancy of figure 5 might be transformed into additional rules like SecRule ARGS:p1 ^\d+$ phase:2,chain SecRule ARGS:pi !^3\.1415$ drop,auditlog

4

6 Current Limitations and Possible Improvements/Extensions

Inheritance A mechanism provided by the mod security rule-language is the possible use of rule-inheritance from parent contexts. The actual version of the meta-language lacks such a feature. This is due to the fact that the resource-specific part of meta-language addresses the properties of valid requests specific to a single resource. To provide a simliar convenient access the definition of global property-groups and their reference from within locationenvironments might be an option in future releases. To achive this a special Global-tag can be used which defines an implication to be associacted with the current and each sub-context.

The language proposed in this paper is a first draft of what might become a useful basis for specifying complex profiles for web applications based on the idea of a positive security model. However, the result in its current state contains several gaps for specifying even more complete and “dynamic” profiles, where by “dynamic” I focus on a stateful description of a users HTTP session when working with a web application. This section contains a (incomplete) list of missing features that I am currently working on or have already solved, but not yet worked into the language.

Version Control Version control itself should be done outside the scope of the meta-language. However tools like xmldiff provide fine-grained patches for XML-trees and may be used for handling different versions of a profile as they provide more XML-oriented differences between these kinds of documents.

Redundancy The use of value and regexp attributes for the tags might be redundant and can possibly shortened by stripping the value attribute. Referenced Implications As already said in 4 the structure of the resulting profile is currently a strict tree and does not allow referencing implications. To improve this, each implication will get an additional id-attribute that uniquely defines the implication. Subsequent elements may then create references to this implication by special *-ref tags where * is one of Parameter,Cookie or Header.

Cool Name :-) Of course, a cool name for the language seems to be one of the most fundamental aspects that is currently missing.

Missing Back-References The current specification of the meta-language lacks a possible reference of variables or variables’ values selected by conditions from within other conditions. A way to improve this is a simple evaluation-language similar to the XPath specification. This would provide access to properties of parent conditions by the use of ${../name} which could express the constraint of the current parameters value to equal the parent locations name. Using these kind of references enables the restriction of parameters encoded into the request-path as stated in the first item of the improvement-list of [5] (page 17).

References [1] Christian Bockermann. Relaxing Positive Security Models for Web Applications, 2007.

Support for Relative Positive Security-Models The current state of the proposed language uses a very strict way of handling violations of the defined restrictions. As this might be wanted in some cases it may lead to false positives in other situations. To overcome this, one approach would be to relax the applications profile which leads to a relative positive security model as defined in [1].

[2] Craig R. McClanahan et. al. Struts - A Framework for Creating Java Web Applications, 2007. [3] C. Kruegel and G. Vigna. Anomaly Detection of Webbased Attacks. In Proceedings of the 10th ACM Conference on Computer and Communication Security (CCS ’03), pages 251–261, Washington, DC, October 2003. ACM Press.

Session Support As most of todays web applications rely on a user-specific context (session) that is associated with each request the meta-language needs to provide the possibility to describe session-specific constraints. This concerns the type of session-mechanism used by the application (e.g. cookie-based, parameter-based) as well as session-oriented rules that need to be checked to prevent attacks like sessionfixation or cookie-stealing. Concepts for session support have already been worked out and probably become part of the next release of the meta-language.

[4] Ivan Ristic. mod security - A Filter-Module for the Apache Webserver, 1998. [5] Ivan Ristic. Portable Protection Recipes for Web Application Defense, 2005. [6] David Scott and Richard Sharp. Abstracting Application-Level Web Security. Technical report, University of Cambridge, 2001.

5