Bridging the Gap Between Web Application Firewalls and
Web Applications
Lieven Desmet, Frank Piessens, Wouter Joosen, and Pierre Verbaeten
DistriNet Research Group, Department of Computer Science
Katholieke Universiteit Leuven, Celestijnenlaan 200A, B-3001 Leuven, Belgium
Lieven.Desmet@cs.kuleuven.be
ABSTRACT
Web applications are the Achilles heel of our current ICT in-
frastructure. NIST’s national vulnerability database clearly
shows that the percentage of vulnerabilities located in the
application layer increases steadily. Web Application Fire-
walls (WAFs) play an important role in preventing exploita-
tion of vulnerabilities in web applications. However, WAFs
are very pragmatic and ad hoc, and it is very hard to state
precisely what security guarantees they offer.
The main contribution of this paper is that it shows how,
through a combination of static and dyn amic verification,
WAFs can formally guarantee the absence of certain kinds
of erroneous behaviour in web applications. We have done
a prototype implementation of our approach building on an
existing static verification tool for Java, and we have applied
our approach t o a medium-sized J2EE based web applica-
tion.
Categories and Subject Descriptors
D.2.4 [Software Engineering]: Software/Program Verifi-
cation; F.3.1 [Logics and Meanings of Programs]: Spec-
ifying and Verifying and Reasoning about Programs
General Terms
Security, verification.
Keywords
Web Application Firewall, shared data rep ository, static ver-
ification, run-time enforcement.
1. INTRODUCTION
Nowadays web applications are wide-spread and more and
more companies incorporate e-commerce in their business
model to increase their revenues. But web applications tend
to be error-prone, and these bugs are a welcome target for
attackers due to their high accessibility and possible p rofit
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
FMSE’06, November 3, 2006, Alexandria, Virginia, USA.
Copyright 2006 ACM 1-59593-550-9/06/0011 ...$5.00.
gain. Therefore, the number of security incidents with web
applications is rapidly increasing [7, 20].
A wide range of countermeasures exists and more recently
Web Application Firewalls (WAFs) are added to the net-
work infrastructure to counter the shortcomings of tradi-
tional network firewalls. WAFs may among others prevent
broken access control vulnerabilities such as vulnerabilities
leading to forceful browsing by enforcing a strict request
flow. One of the problems with using WAFs for the strict
request flow enforcement is the fact that they tend to have
a loose coupling between their configuration and the appli-
cation implementation. In t hat way, th ey can protect appli-
cations against quite general attacks, but there is no direct
relationship to the bugs that actually reside in the appli-
cation they want to protect. Thus, there is no guarantee
that an enforced WAF policy on incoming requests protects
application-specific implementation bugs.
The main contribution of this paper is that it shows how,
through a combination of static and dynamic verification,
WAFs can formally guarantee the absence of certain kinds
of erroneous behaviour in web applications. We have done
a prototype implementation of our approach bu ilding on an
existing static verification tool for Java, and we have applied
our approach t o a med ium-sized J2EE based web applica-
tion. In particular, we guarantee that if the combination of
a web application and a WAF policy passes our verification
process, no client/server interaction will break the data de-
pendencies on the shared session state between server-side
components.
The research presented in this paper is based upon previ-
ous work [8], in which formal contracts specify interactions
with a shared data repository and static verification is used
to guarantee that no data dependencies are broken within
a given software composition. In the previous work, we in-
vestigated app lications with a deterministic, sequential pro-
gram execution, whereas in this paper we model reactive,
indeterministic program execution, combine static and dy-
namic verification, and use semantically richer comp onent
contracts.
The rest of this paper is structured as follows. Section 2
provides some background information on web applications,
web vulnerabilities and Web A pplication Firewalls. Next,
the problem statement is elaborated in section 3 and our so-
lution to guarantee that no client/server interaction leads
to unintended repository interactions is proposed in sec-
tion 4. Section 5 applies the prop osed solution to a small
e-commerce site and section 6 discusses some identified prob-
lems with ESC/Java2, the verification tool that we build
on. In section 7, the presented work is related to existing
research and, finally, section 8 summarises the contributions
of this paper.
2. BACKGROUND
2.1 Web applications
Web applications are server-side applications that are in-
voked by thin web clients (browsers), typically using the
HyperText Transport Protocol (HTTP). A user can navi-
gate through a web application by clicking links or URLs in
his browser, and he is also able to supply input parameters
by completing web forms. A URL maps to a server-resident
program that is executed with the user’s supplied input pa-
rameters. The result of the program execution (often ex-
pressed in the HyperText Markup Language (HTML)) is
then sent back to the browser where it is rendered for fur-
ther user interaction.
HTTP is a stateless, application-level request/response
protocol and has been in use on the World Wide Web since
1990 [9]. Since the protocol is stateless, each request is pro-
cessed independently, without any knowledge of p revious
requests. To enable the typical user’s session concept in a
web app lication, the web application needs to add session
management on top of the stateless HTTP layer. Different
techniques exist to embed web requests within a user ses-
sion such as the use of cookies, URL rewriting or hidden
form fields [28].
Nowadays, most web applications use an underlying frame-
work or web technology to facilitate the development and
the deployment of the web application. Widespread tech-
nologies such as PHP, ASP.NET, JSP/Servlets incorporate
among others the management of user sessions. Next to
tracking to which user session a web request belongs, these
technologies also provide server-side state for each user ses-
sion. While processing a web request, server-side web com-
ponents can store non-persistent, user-specific data (e.g. a
shopping cart in an e-commerce-site) in a data container
bound to the user session. O ther web components can then
retrieve this data while processing future requests in the
same user session.
2.2 Servlet-based web applications
The Java Servlet technology is part of the J2EE specifi-
cation [14] and provides mechanisms for extending the func-
tionality of a web server and for accessing existing business
systems [32]. A J2EE web application is typically a collec-
tion of Java Servlets, deployed in a servlet-based web con-
tainer such as Tomcat, JBoss or WebSphere. Java Servlets
are fun ctional units of the web tier and extra-functional
properties such as load-balancing and security are added to
the webcontainer rather than to the servlets themselves.
The core fun ctionality of the container is to handle in-
coming web requests and to use servlets for processing th e
requests. A container casts incoming HTTP requests into
an object-oriented form (i.e. a HTTPServletRequest object)
and checks to see if there is a servlet registered for process-
ing that request. If there is a match, the request is processed
by the corresponding servlet.
In addition, the J2EE specification also defines filters [31].
A filter operates as a wrapper around the processing servlet
and dynamically intercepts the req uest and response object
before or after the servlet processes the request. Filters are
used to transform or process information cont ained in the
requests or responses. Popular examples are filters for acc-
ces control, for output transformations (such as XSLT), for
logging and auditing.
Servlets and filters are typically stateless components and
operate on a per-request basis. In order t o save non-persistent,
session-relevant state, servlets can store and retrieve data
from a shared data repository (HttpSession) t hat is uniquely
bound t o a user’s session.
2.3 Web vulnerabilities and Web Application
Firewalls (WAFs)
Existing network security fails to effectively protect web
applications against attackers [16]. Network firewalls such
as stateful packet filters typically operate on the network
or transport layer (e.g. granting access to a complete web
application by allowing TCP port 80 traffic), whereas web
applications are typically attacked on the application layer.
For example, attackers exploit among others design flaws in
the application logic and known weaknesses in the HTTP
protocol, the browser or the web server technology. Hence,
a network firewall only addresses network access control in
order to control whether or not a web server can be reached,
irrespective of the kind of web requests and associated data
that is sent to the server.
The Open Web Application Security Project (OWASP)
docu mented the ten most critical web applications v ulner-
abilities in their OWASP Top Ten [23]. In this paper, we
mainly focus on broken access control vulnerabilities, in par-
ticular on vulnerabilities leading to forceful browsing [25].
Forceful browsing is the act of directly accessing web pages
(URLs) without consideration for their context within an ap-
plication session. Bypassing intended application flow can
lead to unauth orised access to resources or unexpected ap-
plication behaviour [35].
To counter web application vulnerabilities, Web Applica-
tion Firewalls (WAFs) operate on the application layer (OSI
layer-7) and analyse web requests between a browser and the
web server [29, 2]. Often, WAFs are placed inline between
the browser and server (as displayed in figure 1), and enforce
real-time access control, based on application-level informa-
tion such as the requested UR L, the supplied credentials and
input parameters and the user session’s history.
A WAF can either use a positive or negative security
model as basis for access decisions. In case of a positive
security model, access control is based upon known positive
behaviour; in case of a negative security model, access is
denied to requests that reflect known dangerous traffic. A
positive security model can be configured manually by the
administrator or can be built automatically by observing
legitimate network traffic.
In the remainder of this paper, we will focus on WAFs
with a positive security model that implement criterion 4.6
of the ”Web A pplication Firewall Evaluation Criteria” [34],
i.e. th e strict request flow enforcement. This criterion refers
to the technique where a WAF monitors individual user ses-
sions and keeps track of the links already followed and of
the links that can be followed at any given time [34].
3. PROBLEM STATEMENT
Without strict request flow enforcement, forceful brows-
ing attacks can compromise the correct functioning of a web
application in various ways. Depending on the application,
Figure 1: Web Application Firewall infrastructure
these attacks can among others circumvent access control or
input validation, can corrupt server-side state or can bring
the server in an inconsistent state and thus result in unex -
pected behaviour. More generally, the outcome of tamper-
ing with the client/server protocol can break the application
logic or trigger server-side bugs.
WAFs with strict requ est flow enforcement are accepted
as an effective countermeasure for forceful browsing attacks.
However, since WAFs are mainly configured in a heuris-
tic way, either manually or by observing legitimate network
traffic, they tend to have a loose coupling between their con-
figuration and the application implementation. Therefore,
no formal guarantees can be given about the effectiveness of
applying a WAF policy to protect against certain types of
implementation bugs.
In section 4, we p ropose our solution to formally bridge
the gap between the WA F enforcement policy and the web
application. By combining static verification and dynamic
enforcement, we are able to guarantee that the enforcement
engine used protects the application against certain types of
application-specific implementation bugs. Although we re-
strict our focus in this paper to errors that can occur on the
non-persistent, server-side session state, we strongly believe
that our approach is also applicable to other typ es of imple-
mentation bugs or infringements of the application logic.
In the next paragraph, a simple servlet-based web app li-
cation illustrates the kind of errors that can occur on the
server-side session state due to forceful browsing. We will
then retake this application in sections 4 and 5 to clarify
parts of our solution. Although we mainly use servlets in
this paper as an illustration, the problem is as well valid in
other web technologies such as ASP.NET or PHP, and our
solution could be applied there as well.
The Duke’s BookStore web application.
The Duke’s BookStore web application is an exemplary Java
Servlet application that is bundled together with the J2EE
1.4 Tutorial [1]. This small e-commerce application consists
of about 4000 lines of code, and implements the basic func-
tionality of a web shop by using Java Servlets. The core
application logic is supplied by 6 servlets and 1 filter:
Book StoreServlet The BookStore servlet returns the main
web p age for the Duke’s Bookstore. From th is start
page, links are provided to browse the book catalog,
or jump to the b ookdetails of a particular book (e.g.
a book in promotion).
Book DetailsServlet The BookDetail servlet returns in-
formation about any bo ok that is available from the
bookstore. A user can either add the book to the shop-
ping cart, or look further into the book catalog.
CashierServlet The Cashier servlet asks for the user’s name
and credit card number so t hat the user can buy the
books in his shopping cart. Payment information is
sent to the Receipt servlet.
CatalogServlet The Catalog servlet displays the book cat-
alog, and provides the possibility to add books to the
user’s shopping cart or to buy the books in the shop-
ping cart by redirecting to the cashier servlet.
ReceiptServlet The Receipt servlet processes the order by
updating the book database inventory. Afterwards the
servlet invalidates the user session.
ShowCartServlet The ShowCart servlet returns informa-
tion about the books in the user’s shopping cart.
OrderFilter The Order filter provides server-side logging
of shopping orders, whenever t he ReceiptServlet is called.
These components interact with the shared session repos-
itory as listed in table 1. The interactions are specified by
a type (e.g. ResourceBundle), a string identifier (e.g. mes-
sages) and the type of interaction. The interaction types
used in table 1 are more fine-grained that just simple read
and write operations. The type def. read/write stands for a
defensive read/write operation as shown in listing 1, i.e. the
application can handle a null pointer as result of the read op-
eration, and in that case the servlet stores a not null object
of the expected type to the shared session repository. The
label cond. means that th e operation possibly occurs, de-
pending on an unspecified condition such as run-time state
of the book database inventory.
Listing 1: Example of a defensive read/write oper-
ation in BookDetai lsServlet
Currency c = (Currency) session.getAttribute("currency");
if (c == null) {
c = new Currency();
session .setAttribute("currency", c);
}
Session repository interactions are typically not specified
in a Servlet- based application, and neither they are in this
J2EE tu torial application. Thus, the implicit assumptions of
the developer on how a servlet or filter should be used with
respect to its interactions with the shared session repository
are not shipped together with the source code. This makes
correct deployment or software evolution very hard without
reanalysing t he complete source code.
Book DetailsServlet: CashierServlet:
ResourceBundle messages (read) ResourceBundle messages (read)
Currency currency (cond. def. read/write) ShoppingCart cart (def. read/write)
Currency currency (def. read/write)
Book StoreServlet :
ResourceBundle messages (def. read/write) CatalogServlet:
ResourceBundle messages (read)
ReceiptServlet: ShoppingCart cart (def. read/write)
ResourceBundle messages (read) Currency currency (def. read/write)
ShoppingCart cart (def. read/write)
ShowCartServlet:
OrderFilter: ResourceBundle messages (read)
ShoppingCart cart (read) ShoppingCart cart (def. read/write)
Currency currency (read) Currency currency (cond. def. read/write)
Table 1: Interactions w ith the shared session reposi tory in the BookStore application
Even in this small e-commerce application, the interac-
tions with the shared session repository impose restrictions
on the allowed client/server interaction protocol. If for ex-
ample a user session starts with any URL path oth er t han
the /bookstore starting point of the app lication (which is
a typical forceful browsing attack), the ex ecu tion of any
servlet ends up with a NullPointerException: every servlet
retrieves the messages data item from the shared repository
and assumes in its execution that the retrieved Resource-
Bundle is not null. Another Null PointerException occurs
in this small application if the OrderFilter (applied on the
ReceiptServlet) is called in a user’s session before the cart
and currency data items are stored to the shared repository.
The problem does however not occur if t he OrderFilter is
not applied to the ReceiptServlet, which may indicate that
this error was introduced to the application due t o evolution.
The impact of a NullPointerException during execution
depends on the particular application. Possible consequences
include the execution of unexpected application logic, infor-
mation leakage due to bad error handling, b roken data in-
tegrity by storing null strings to the database back-end, skip-
ping of clean-up code (such as the co de that closes database
connections) which in turn may lead to a Denial-of-Service,
and many more. In the remainder of this paper we assume
that the occurrence of a NullPointerException due to data
rep ository interactions in a web application negatively af-
fects the security of the application and thus should be pre-
vented from happening. More precisely, we define th e de-
sired application property as follows:
No broken data dependencies in the user’s session
shared data repository:
No client request causes a data item to be read from
the server-side, shared session repository before it is
actually written. For each shared data read interaction,
the shared data item that is already written to the shared
session repository is of the type expected by the read
operation.
4. SOLUTION
In this section we propose our solution: we specify a com-
ponent’s interactions with the shared session repository and
use static and dynamic verification to guarantee th at no
client/server interactions leads to violation of th e the de-
sired application property. Figure 2 depicts an overview
of our solution. At the left side of the figure the different
artifacts of our application are listed. Next to the imple-
mentation and the deployment information, also the WAF
strict flow enforcement policy and the run-time web traffic
are used as input for our verification process.
The verification process consists of three steps. Firstly,
the interactions with th e shared session repository are ex-
plicitly specified in component contracts, and static verifica-
tion is used to verify that the component implementations
obey to the contract specification. Secondly, static verifica-
tion ensures that any client/server interaction proto col that
complies to the WAF enforcement policy actually satisfies
the component’s preconditions on the shared session reposi-
tory. Finally, run-time policy enforcement is used to guaran-
tee that only web requests that obey the WAF enforcement
policy are allowed to be processed by the web application.
By combining these three verification steps, our solution en-
sures the desired application property. Our solution is sound
(if the assumptions underlying our pragmatic framing hold
for the application being protected, see subsection 6.2). Our
solution is however not complete: to avoid undecidability is-
sues, the static verification is necessarily conservative.
Server-side specification and verification
In order to specify a component’s interactions with the shared
session repository, each web component is extended with an
appropriate component contract. The contract is expressed
in a problem-specific contract language, which is easy to
understand for application developers. Listing 2 for exam-
ple, shows such a problem-specific contract of the ShowCart-
Servlet, which is a straightforward mapping of the interac-
tions specified in table 1. Next, static verification is used
to verify t hat a component’s implementation obeys its con-
tract, i.e. that only the read and write interactions happen
that are specified in the contract.
Application-specific protocol verification
As the first input artifact for the application-specific proto-
col verification, the strict enforcement policy of the WAF is
required. This representation of the intended client/server
interaction protocol can be expressed in various ways such
as a regular expression, an EBNF notation or a labelled
state transition system. For example, listing 3 and figure 3
Figure 2: Solution overview
Listing 2: Problem -specific specification of ShowCartServlet
//spec: reads {ResourceBundle messages, Nullable<ShoppingCart> cart, Nullable<Currency> currency} from session;
//spec: writes {cart == null => ShoppingCart cart} on session;
//spec: possible writes {currency == null => Currency currency } on session;
are two different representations of the intend ed protocol for
the Duke’s BookStore application.
In order to statically verify that any client/server inter-
action (that conforms to the intended protocol) d oes not
violate the desired application property, the intended proto-
col is verified in combination with the component’s contracts
in a given deployment. In a J2EE web application for exam-
ple, the web deployment descriptor contains among others
the mapping between URLs and servlets, as well the servlets
on which filters are applied.
Run-time protocol enforcement
Finally, the verified client/server protocol needs to be en-
forced at run-time. This is done by loading the protocol
specification into a supporting WAF.
5. PROTOTYPE IMPLEMENTATION
In this section, we describe our prototype implementation
an discuss how it can be used to secure the Duke’s BookS tore
application.
5.1 Server-side specification and verification
In order to use ex isting verifiers to check if the implemen-
tation of a component adheres to its contract, the problem-
specific contracts are translated into the Java Modeling Lan-
guage (JML) [18] which is a p opular formal contract speci-
fication language for components written in Java.
The JML contract in listing 4 expresses interactions be-
tween actions and the shared data repository in terms of
pre- and post-state of the repository. For read interactions,
the component’s contract indicates that the component re-
quires that a non-null data item of the specified type can
be read from the shared repository. For write interactions,
the ensures pragma states which data items on the sh ared
rep ository will be non-null and of the specified type after
method execution. In Listing 4 for example, the JML con-
tract of the doGet method of the ShowCartServlet states
that among others the shared data item messages will be a
non-null ResourceBundle object before execution and after
execution that the data item cart is ensured to be a non-null
ShoppingCart. In addition, the modifies clause expresses the
frame condition, i.e. what part of the session state a method
is allowed to modify.
Finally, notice the use of the also keyword. The Show-
CartServlet ext ends the HttpServlet, and by doing so it in-
herits the public method specification of the doGet method.
To refine the specification of an overrided method (e.g. by
weakining preconditions or by strengthening postconditions),
the specification in JML starts with the also keyword, which
combines the specifications of the supertype and the sub -
type. Similarly, the also keyword can also be used in regular
specification to combine different specification blocks into a
nested specification. More information about the desugaring
of also combinations in JML can b e found in [27, 6].
Since the doGet method of the HttpServlet does not pro-
vide common behavior for all the inheriting servlets, the
supertype method is annotated with the strongest possible
precondition, i.e. the requires false pragma. In this way,
all inheriting servlets are able to weaken this precondition
conform the Liskov principle.
One of the main advantages of JML is the large amount
of tool support that is available [5]. Tools are available for
run-time contract checking, test generation, static verifica-
tion and inference of specifications. A variety of static ver-
ification tools is available that make different trade-offs in
verification power and need for user interaction.
In our prototype, we chose to use the ESC/Java2 veri-
fier [17]. The main advantage of this verifier is that it re-
quires no user interaction. On the downside, the verifier
is far from complete, for instance reasoning about loops is
fairly weak. In addition, some known sources of unsound-
ness [19, 6] regarding to framing and reentrancy should be
avoided.
