Web Application Profiles

The Web Application Profiles of the JWall system constitute a highlevel XML description of web applications which serve as basis for positive security models for the applications. The description is based upon a clean and easily understandable XML schema, the Web Profile Language.

The use of XML allows for a specification of a white-listing approach which is independent of the web application firewall or validation system that is to be used. As one of the first WAF systems that the profiles can be used in, we provide a Java based compiler for transforming the profiles into a ruleset for the ModSecurity module.

In order to ease the creation of such a positive security model for an application, jwall.org provides two approaches:

The ProfileEditor is a standalone Java application which allows loading, editing and compiling (i.e. transformation into ModSecurity rules).

In addition to a plain white-listing approach, the XML language and the ProfileEditor allow for the integration of existing pattern-based approaches like PHP-IDS or even the Core Rules provided with the ModSecurity module. For more details on this integration see mixed models.

Language Concept

The basic concept of the Web Profile Language is a hierarchical decomposition of a web application by means of the applications address space, i.e. URLs of its resources. This natural view of the application provides an understandable display of resources and natively fits the conceptual view of web applications as defined by J2EE, PHP and other web environments.

The language depends on nesting descriptions of your application's resources which results in a description.

Having said this, we can artlessly interpret an application as a hierarchical ordered set of resources which are identified by their URLs. Describing your application by specifying all resources that shall be accessable lets you check for a first class of common security issues of web applications: unwanted exposure of sensitive files.

The following figure 1 shows the hierarchical decomposition of a simple web application that consists of a small number of resources. Each resource is further specified in more details by more nested elements describing the request properties valid for this resource.


Figure 1: Resource tree of an application.

The Web Profile Language provides Resource elements for describing a resource and by nesting resources the above tree structure can easily be described with the profile language. The resources are further described by nesting additional XML elements within a certain resource's element. As pointed out in the figure above the resource /intern/account.php can be described by nesting a Method element and Parameter elements within the resource description:

   ...
     <Resource name="intern">
         <Resource name="account.php">

             <Parameter name="id" type="${SessionId}" scope="header" />

             <Method value="GET">
                <!--
                    Description of the resource /intern/account.php, 
                    when accessed using a GET request
                -->
             </Method>

             <Method value="POST">
                <!--
                    Description of the resource /intern/account.php
                    when accessed with a POST request
                  -->
             </Method>

         </Resource>
     </Resource>
   ...

As another feature to ease the creation of such profiles, the language allows for the specification and use of pre-defined resource classes and parameter types. These can be used in a way similar to the inheritance of modern object oriented programming languages.

In the example from above, the parameter type SessionID is a user-defined type that is referenced by issuing ${SessionID} in the type attribute of the parameter element.

A more sophisticated example is the definition and use of a resource class. This class defines several methods and parameters that can be inherited by other resources. Let the following be the definition of a resource class:

    <ResourceClass name="Image">
       <Method value="GET|HEAD" />
    </ResourceClass>

Then we can easily define image resources by creating a Resource element within our profile's resource tree, and let it extend the Image class:

    <Resource name="images">
       <Resource name="[a-z0-9]{4,8}\.gif" extends="Image" />
    </Resource>

As you can probably easily guess from this simple example, this small XML snippet will specify a set of resources which match the path /images/[a-z0-9]{4,8}\.gif and which inherit the valid request properties from the Image class.

Thus, the images matching the specified path(s) can be accessed using a simple GET or HEAD method. Similar definitions can also be made for specific headers, authorization or parameters.

After this small overview of the language concept, we will go into more details within the next sections. The next session gives a description of the basic elements of the language. After this, we describe the concept of inheritance within the language in section Abstraction.

1. Components of a Profile

An application's profile consists of a set of different resources, each of which represents a component of the application. The resources are structured according to the herarchical nature of the URL addressing scheme. Given some basic context path "/", the application consists of all resources contained within that base path.

Defining Resources

Basic to the profile definition is the resource tree which represents the whole hierarchical structure of an application which is described in the following. In addition to that the profiles may include some meta-information that is providing the author and the version of a profile.

Specifying a resource by its URL is thus the first step in describing a part of the application. This is achieved by splitting the URL into path-elements, for example, the resource /images/logo.gif will be specified as follows:

    ...
    <Resource name="images">
        <Resource name="logo.gif">

        </Resource>
    </Resource>
    ...

Within the inner Resource-tag the legal properties of requests to that resource will be described. Since profiles define a positive security-model, the above definition needs a little bit more to be accessible. In the following we extend the resource-definition to allow GET-requests to come through:

    ...
    <Resource name="images">
        <Resource name="logo.gif">
            <Method value="GET" />
        </Resource>
    </Resource>
    ...

This will reflects all GET-requests without any parameter to be legal requests to images/logo.gif. Nearly all attributes (i.e. a resources' name, a methods' value) allow for the use of regular expressions which enables you to specify more than just one method at a time. For example to allow HEAD-requests in addition to only the GET-method you can extend the definition above by using

    ...
        <Method value="(GET|HEAD)" />
    ...

Specifying Valid Parameters

A lot of the attacks against web applications can be prevented by using a strict type system on parameters. This is the first objective of the parameter specifications within the Web Profile Language. The definition of parameter types mostly relies on standard regular expressions.

The use of regular expressions allows the specification of a lot of simple parameter type as well as an application specific typing mechanism, e.g. the defintion of a fixed set of legal parameter values as mostly within select fields.

The basic element for specifying a parameter is called Parameter. It has an attribute name for refering to the parameter's name. This attribute also takes regular expressions for specifying type properties for a set of parameters. The following example specifies a simple ID parameter which takes an hexadecimal session ID of exactly 32 digits:

     <Parameter name="ID" regexp="[a-fA-F0-9]{32,32}" required="false" scope="header" />

Obviously, the required-attribute specifies that this parameter has to be present within a request. Using the scope attribute allows you to distinguish between parameters sent within the header, i.e. query-string, and those transmitted in the request-body.
The following table lists all attributes of the Parameter element:

AttributeDescription
name This attribute specifies the name of the header or cookie that is checked using the regular expression.
regexp This attribute contains either a regular expression that is used for checking the header or cookie, or a reference, starting with a $ character, which references a pre-defined regular expression.
required A parameter can either be optional or required. A value of true for this attribute will require the parameter to be present within the request (besides matching the regular expression).
scope Parameters can be transmitted either within the query string, i.e. the request header, or the message body, e.g. within a POST request. This attribute allows for the user to specify either the header or body scope for a request.

The Parameter element can be nested into several of the elements described so far: Resource, for defining a parameter type which covers all possible methods, or within the Method element, to restrict the parameter in dependency of the request-method.

Parameters can even be dependent on each other, i.e. a certain parameter is only required to be present in case of another one. In the following snippet, the parameter productID is mandatory if the parameter action has the specific value "show":

     <Parameter name="action" regexp="show" required="false" scope="header" >
        <Parameter name="productID" regexp="\d{5,10}" required="true" scope="header" />
     </Parameter>

Specifying Headers and Cookies

The element Parameter is very universal and a central part of the profile language. Similar to checking the types of parameters, it is also possible to use the Header and Cookie elements for type checking header fields and request cookies.

As with the Parameter element, the elements Header and Cookie provide similar attributes, which are listed within the following table:

AttributeDescription
name This attribute specifies the name of the header or cookie that is checked using the regular expression.
regexp This attribute contains either a regular expression that is used for checking the header or cookie, or a reference, starting with a $ character, which references a pre-defined regular expression.
required A header and a cookie can either be optional or required. A value of true for this attribute will require the header or cookie to be present within the request (besides matching the regular expression.

Obviously, the Header and Cookie elements do not provide the scope attribute as these properties are header properties.

Abstraction

The concept of abstraction is a very important and powerful property of the Web Profile Language. It lets you define request- or resource properties in an efficient and re-usable manner by allowing Resource elements to extend pre-defined resource classes.

This is the same principle that you probably already know from object oriented languages like Java, objective PHP or the like, which makes it even more attractive to be utilized by users.

Written by Christian Bockermann <chris@jwall.org>
Any feedback is welcome.