**A Guided Web Service Security Testing Method**

Sébastien Salva

*LIMOS UMR CNRS 6158, University of Auvergne France*

#### **1. Introduction**

For the last five years, the Internet is being revolutionized by becoming a Service-oriented platform. This tremendous inflection point in Computer Science leads to many new features in design and development such as the deployment of interoperable services accessible from Web sites or standard applications, the modelling of high level Business processes orchestrating Web Service sets, or recently the virtualization of service-based applications by means of the Cloud paradigm.

To achieve reliable Web services, which can be integrated into compositions or consumed without any risk in an open network like the Internet, more and more software development companies rely on software engineering, on quality processes, and quite obviously on testing activities. In particular, security testing approaches help to detect vulnerabilities in Web services in order to make them trustworthy. Nevertheless, it is quite surprising to notice that few security testing methods have been proposed for Web Services. This chapter addresses this issue by presenting a formal security testing method for stateful Web Services. Such services are persistent through a session and have an internal state which evolves over operation call sequences. For instance, all the Web Services using shopping carts or beginning with a login step are stateful. The proposed method aims to experiment *black box* Web Services, from which only SOAP messages (requests and responses) are observable. We do not have access to the code, Web services can be experimented only through their interfaces. Our approach is an active Model Based one: it relies on a specification formalized with a model to test Web services by means of test cases generated from the model. Model based testing approaches offer many advantages such as the description of a service without ambiguity. Accompanied with a formal method, some steps of the test can be also automated, e.g., the test case generation Rusu et al. (2005); Tretmans (2008). The use of a model also helps to define a relation between the specification and its black-box implementation to express clearly the confidence level between them. In this paper, we model Web services with Symbolic Transition Systems (STS Frantzen et al. (2005)) describing the different states, the called operations and the associated data.

In literature, for the same reasons, security policies are often described by means of formal rules, which regulate the nature and the context of actions that can be performed. Several security rule languages have been introduced in Cuppens et al. (2005); Senn et al. (2005). We have chosen Nomad (Non atomic actions and deadlines Cuppens et al. (2005)) to model abstract test patterns which can be directly derived from an existing security rule set. Nomad is well suited for expressing properties such as permissions, prohibitions or obligations and

Atomic Actions and Deadlines Cuppens et al. (2005)), or OrBAC (Organisation-based access

A Guided Web Service Security Testing Method 197

Some other papers, focusing on security rule modelling and formal testing, have been proposed in literature. Modelling specifications for testing and defining formal methods is more and more considered in literature and in industry because this offers many advantages such as the definition of the confidence level of the implementation in comparison with its specification, the coverage of the tests, or the automation of some steps. An overview of

• *Test Generation for Model-based Policies*. Test generation methods for model-based policies construct abstract test cases directly from models describing policies. For instance, Le Traon et al. Le Traon et al. (2007) proposed test generation techniques to cover security rules modelled with OrBAC. They identified rules from the policy specification and generated abstract test cases to validate some of them. Senn et al. showed, in Senn et al. (2005), how to formally specify high-level network security policies, and how to automatically generate test cases, by using the specification. In Darmaillacq et al. (2006), network security rules are tested by modelling the network behaviour with labelled transition systems. Then, test patterns are injected into existing test cases to validate the

• *Random Test Generation:* or fuzzy testing is a technique which automatically or semi-automatically constructs test cases with random values. For instance, in Martin (2006), the authors developed an approach for random test generation from XACML policies. The policy is analyzed to generate test cases by randomly selecting requests from

• *Mutation testing:* usually involve mutation of policies or programs. In Mouelhi et al. (2008), the authors proposed a model-driven approach for specifying testing security policies in Java applications. The policy is modelled with a control language such as OrBAC and translated into XACML. Then, the policy is integrated into the application. Faults are injected into the policy to validate the policy in the application by mutating the original

Concerning, the Web service security testing, which is the topic of the chapter, few dedicated works have been proposed. In Gruschka & Luttenberger (2006), the passive method, based on a monitoring technique, aims to filter out the SOAP messages by detecting the malicious ones to improve the Web Service's availability. Mallouli et al. also proposed, in Mallouli et al. (2008), a passive testing method which analyzes SOAP messages with XML sniffers to check whether a system respects a policy. In Mallouli et al. (2009), a security testing method is described to test systems with timed security rules modelled with Nomad. The specification is augmented by means of specific algorithms for basic prohibition and obligation rules only. Then, test cases are generated with the "TestGenIF" tool. A Web Service is illustrated as an

Our first motivation comes from the paper Mallouli et al. (2009) which describes a testing method from Nomad rules. This one can handle basic rules composed of abstract actions only and can be applied on generic systems. In this book chapter, we intend to propose a specific security testing method which takes into account black box Web Services deployed in a SOAP

control Kalam et al. (2003)).

rules.

security rules.

example.

the set of all possible requests,

model based testing is given in Tretmans (2008).

These works can be grouped into the following categories:

is able to take into account response delays. Our approach takes a Web Service specification and applies abstract test patterns on the operation set to generate test requirements called test purposes. These ones, which guide the tests, are then synchronized with the specification to produce the test case suite. The latter checks the satisfiability of the test relation *secure*, which formally defines the security level between the implementation and its specification combined with test purposes. The Amazon E-commerce Web Service (AWSECommerceService) Amazon (2009) is illustrated as an example on which we apply our method.

Another part of the book chapter is dedicated to the experimentation of the method on existing Web Services with an academic tool. The obtained results demonstrate a dramatic lack of security in many Web Services since 11 percent dot not satisfy the restrictions given by our security test patterns.

This book chapter is structured as follows: Section 2 provides an overview of the Web Service paradigm and on some related works about Web Service security testing. Sections 3 and 4 describe the Web service and test pattern modelling respectively. The testing method is detailed in Section 5. In Section 6, we discuss some experimentation results, the test coverage and the complexity of the method. Finally, Section 7 gives some perspectives and conclusions.

### **2. Web services security overview**

Web Services are *"self contained, self-describing modular applications that can be published, located, and invoked across the Web"* Tidwell (2000). To ensure the Web Service interoperability, the WS-I organization has suggested profiles, and especially the WS-I basic profile WS-I organization (2006), composed of four major axes: the Web Service interface description with the WSDL language (Web Services Description Language World Wide Web Consortium (2001)), the definition and the construction of XML messages, based upon the Simple Object Access Protocol (SOAP World Wide Web consortium (2003)), the service discovery in UDDI registers (Universal Description, Discovery Integration Specification (2002)), and the Web service security, which is obtained by using the HTTPS protocol.

It is surprising to notice that security was the poor relation during the rush to Web Services and it is manifest that the HTTPS protocol was not sufficient to fulfill the security requirements of service-based applications. We can now find a tremendous set of documents and specifications related to Service security. The WS-security standard (Web Service Security OASIS consortium (2004)) gathers most of them. This document describes a SOAP rich extension to apply security to Web services by bringing message encryptions, message signing, security token attachment, etc. Both the policy requirements of the server side and the policy capability of the client side can be expressed by means of the WS-Policy specification. Nevertheless, this one is "only" SOAP-based, and defines requirements on encryption, signing or token mechanisms. Higher level rules cannot be expressed with WS-Policy.

Besides these specifications, several academic papers Gruschka & Luttenberger (2006); ISO/IEC (2009); Singh & Pattterh (2010) and the OWASP organization OWASP (2003) focused on Service security in regard to access control by decomposing it into several criteria: availability, integrity, confidentiality, authorization, authentication and freshness and by proposing recommendations for each one. Each criterion can be also modelled formally by means of security rules written with languages such as XACML (eXtensible Access Control Markup Language OASIS standards organization (2009)), Nomad (Security Model with Non 2 Will-be-set-by-IN-TECH

is able to take into account response delays. Our approach takes a Web Service specification and applies abstract test patterns on the operation set to generate test requirements called test purposes. These ones, which guide the tests, are then synchronized with the specification to produce the test case suite. The latter checks the satisfiability of the test relation *secure*, which formally defines the security level between the implementation and its specification combined with test purposes. The Amazon E-commerce Web Service (AWSECommerceService) Amazon

Another part of the book chapter is dedicated to the experimentation of the method on existing Web Services with an academic tool. The obtained results demonstrate a dramatic lack of security in many Web Services since 11 percent dot not satisfy the restrictions given by our

This book chapter is structured as follows: Section 2 provides an overview of the Web Service paradigm and on some related works about Web Service security testing. Sections 3 and 4 describe the Web service and test pattern modelling respectively. The testing method is detailed in Section 5. In Section 6, we discuss some experimentation results, the test coverage and the complexity of the method. Finally, Section 7 gives some perspectives and conclusions.

Web Services are *"self contained, self-describing modular applications that can be published, located, and invoked across the Web"* Tidwell (2000). To ensure the Web Service interoperability, the WS-I organization has suggested profiles, and especially the WS-I basic profile WS-I organization (2006), composed of four major axes: the Web Service interface description with the WSDL language (Web Services Description Language World Wide Web Consortium (2001)), the definition and the construction of XML messages, based upon the Simple Object Access Protocol (SOAP World Wide Web consortium (2003)), the service discovery in UDDI registers (Universal Description, Discovery Integration Specification (2002)), and the Web service

It is surprising to notice that security was the poor relation during the rush to Web Services and it is manifest that the HTTPS protocol was not sufficient to fulfill the security requirements of service-based applications. We can now find a tremendous set of documents and specifications related to Service security. The WS-security standard (Web Service Security OASIS consortium (2004)) gathers most of them. This document describes a SOAP rich extension to apply security to Web services by bringing message encryptions, message signing, security token attachment, etc. Both the policy requirements of the server side and the policy capability of the client side can be expressed by means of the WS-Policy specification. Nevertheless, this one is "only" SOAP-based, and defines requirements on encryption, signing

Besides these specifications, several academic papers Gruschka & Luttenberger (2006); ISO/IEC (2009); Singh & Pattterh (2010) and the OWASP organization OWASP (2003) focused on Service security in regard to access control by decomposing it into several criteria: availability, integrity, confidentiality, authorization, authentication and freshness and by proposing recommendations for each one. Each criterion can be also modelled formally by means of security rules written with languages such as XACML (eXtensible Access Control Markup Language OASIS standards organization (2009)), Nomad (Security Model with Non

or token mechanisms. Higher level rules cannot be expressed with WS-Policy.

(2009) is illustrated as an example on which we apply our method.

security test patterns.

**2. Web services security overview**

security, which is obtained by using the HTTPS protocol.

Atomic Actions and Deadlines Cuppens et al. (2005)), or OrBAC (Organisation-based access control Kalam et al. (2003)).

Some other papers, focusing on security rule modelling and formal testing, have been proposed in literature. Modelling specifications for testing and defining formal methods is more and more considered in literature and in industry because this offers many advantages such as the definition of the confidence level of the implementation in comparison with its specification, the coverage of the tests, or the automation of some steps. An overview of model based testing is given in Tretmans (2008).

These works can be grouped into the following categories:


Concerning, the Web service security testing, which is the topic of the chapter, few dedicated works have been proposed. In Gruschka & Luttenberger (2006), the passive method, based on a monitoring technique, aims to filter out the SOAP messages by detecting the malicious ones to improve the Web Service's availability. Mallouli et al. also proposed, in Mallouli et al. (2008), a passive testing method which analyzes SOAP messages with XML sniffers to check whether a system respects a policy. In Mallouli et al. (2009), a security testing method is described to test systems with timed security rules modelled with Nomad. The specification is augmented by means of specific algorithms for basic prohibition and obligation rules only. Then, test cases are generated with the "TestGenIF" tool. A Web Service is illustrated as an example.

Our first motivation comes from the paper Mallouli et al. (2009) which describes a testing method from Nomad rules. This one can handle basic rules composed of abstract actions only and can be applied on generic systems. In this book chapter, we intend to propose a specific security testing method which takes into account black box Web Services deployed in a SOAP

*•* <sup>Λ</sup> *is the finite set of symbols, partitioned by* <sup>Λ</sup> <sup>=</sup> <sup>Λ</sup>*<sup>I</sup>* <sup>∪</sup> <sup>Λ</sup>*O: inputs, beginning with ?, are provided*

A Guided Web Service Security Testing Method 199

*•* → *is the finite transition set. A transition* (*li*, *lj*, *a*(*p*), *ϕ*, *�*)*, from the location li* ∈ *L to lj* ∈ *L, also*

The STS model is not specifically dedicated (restricted) to Web services. This is why we assume that an action *a*(*p*) represents either the invocation of an operation *op* which is denoted *opReq* or the return of an operation with *opResp*. Furthermore, Web service are object-oriented components which may throw exceptions. So, we also model exception

For simplicity and to respect the WS-basic profile, we assume that operations either always return a response or never (operations cannot be overloaded). We also assume that STSs are deterministic. As a consequence, we suppose that operations are synchronous, i.e. these ones return a response immediately or do nothing. Asynchronous methods may return a response

An immediate STS extension is called the STS *suspension* which also expresses quiescence i.e., the absence of observation from a location. Quiescence is expressed with a new symbol !*δ* and an augmented STS denoted Δ(*STS*). For an STS S, Δ(S) is obtained by adding a self-loop labelled by !*δ* for each location where quiescence may be observed. The guard of this new transition must return true for each value of *DV*∪*<sup>I</sup>* which does not allow firing a transition

*where p is a finite set of parameters p* = (*p*1, ..., *pk*)*. We denote type*(*p*)=(*t*1, ..., *tk*) *the type of*

*firing of the transition. Internal variables are updated with the assignment �* : *DV* × *Dp* → *DV*

*<sup>n</sup>*≥<sup>0</sup> *is an action*

*<sup>n</sup>*≥0*, <sup>ϕ</sup>* <sup>⊆</sup> *DV* <sup>×</sup> *Dp is a guard which restricts the*

*to the system, while outputs (beginning with !) are observed from it. a*(*p*) <sup>∈</sup> <sup>Λ</sup> <sup>×</sup> *<sup>I</sup><sup>n</sup>*

*the variable set p, and Dp the variable domain in which p takes values,*

−−−−→ *lj is labelled by a*(*p*) <sup>∈</sup> <sup>Λ</sup> <sup>×</sup> *<sup>I</sup><sup>n</sup>*

messages with a particular symbol denoted !*exp* <sup>∈</sup> <sup>Λ</sup>*O*.

anytime, from several states and often imply indeterminism.

*denoted li*

labelled by an output.

Fig. 1. An STS specification

*a*(*p*),*ϕ*,*�*

*once the transition is fired.*

environment that is used to invoke operations. We claim that SOAP must be considered while testing since it modifies the Web Service behaviour and thus may falsify the testing verdict. So, in Section 3.2 we study the Web service consuming with SOAP and propose a specification completion to take it into account in the test case generation.

We consider the access control-based vulnerabilities expressed in OWASP (2003) to describe some security test patterns composed of actions such as operation requests. Actually, we specialize our test patterns for Web services to experiment our method. So, test patterns are composed of malicious requests (XML and SQL injections) for testing the Web Service availability, authentication and authorization. They also contain different variable domain sets such as *RV* composed of values well-known for detecting bugs and random values, or *Inj* composed of values for both SQL and XML injections. So, our method covers several categories cited previously (model-based and random testing). Then, we present a dedicated testing methodology, based upon a formal security test relation, denoted *secure* which expresses, without ambiguity, the security level of an implementation with regard to its specification and to a set of test patterns. To check the satisfiability of *secure*, test patterns are translated into test purposes. Then, concrete test cases are generated by means of a synchronous product between the specification and test purposes. Intuitively, we obtain action sequences, extracted from the specification and also composed of the initial test pattern properties. Our test purpose-based method helps to reduce the specification exploration during the test case generation and thus reduces the test costs Castanet et al. (1998).

Prior to present the testing methodology, we define the Web service modelling below.

### **3. Web Service modelling in SOAP environments**

Several models e.g., UML, Petri nets, process algebra, abstract state machines (ASM), have been proposed to formalize Web services. STSs (Symbolic Transition Systems Frantzen et al. (2005)) have been also used with different testing methods Frantzen et al. (2006); ir. H.M. Bijl van der et al. (2003); Salva & Rabhi (2010). The STS formalism offers also a large formal background (process algebra notations, definitions of implementation relations, test case generation algorithms, etc.). So, it sounds natural to use it for modelling specifications and test cases. Below, we recall the background of the STS formalism and the specification completion to take into account the SOAP environment.

#### **3.1 Stateful Web Service modelling**

An STS is a kind of input/output automaton extended with a set of variables, with guards and assignments on variables labelled on the transitions. The action set is separated with inputs beginning by ? to express the actions expected by the system, and with outputs beginning by ! to express actions produced (observed) by the system. Inputs of a system can only interact with outputs provided by the system environment and vice-versa.

**Definition 1.** *A Symbolic Transition System STS is a tuple < L*, *l*0, *V*, *V*0, *I*, Λ, →*>, where:*


4 Will-be-set-by-IN-TECH

environment that is used to invoke operations. We claim that SOAP must be considered while testing since it modifies the Web Service behaviour and thus may falsify the testing verdict. So, in Section 3.2 we study the Web service consuming with SOAP and propose a specification

We consider the access control-based vulnerabilities expressed in OWASP (2003) to describe some security test patterns composed of actions such as operation requests. Actually, we specialize our test patterns for Web services to experiment our method. So, test patterns are composed of malicious requests (XML and SQL injections) for testing the Web Service availability, authentication and authorization. They also contain different variable domain sets such as *RV* composed of values well-known for detecting bugs and random values, or *Inj* composed of values for both SQL and XML injections. So, our method covers several categories cited previously (model-based and random testing). Then, we present a dedicated testing methodology, based upon a formal security test relation, denoted *secure* which expresses, without ambiguity, the security level of an implementation with regard to its specification and to a set of test patterns. To check the satisfiability of *secure*, test patterns are translated into test purposes. Then, concrete test cases are generated by means of a synchronous product between the specification and test purposes. Intuitively, we obtain action sequences, extracted from the specification and also composed of the initial test pattern properties. Our test purpose-based method helps to reduce the specification exploration

during the test case generation and thus reduces the test costs Castanet et al. (1998). Prior to present the testing methodology, we define the Web service modelling below.

Several models e.g., UML, Petri nets, process algebra, abstract state machines (ASM), have been proposed to formalize Web services. STSs (Symbolic Transition Systems Frantzen et al. (2005)) have been also used with different testing methods Frantzen et al. (2006); ir. H.M. Bijl van der et al. (2003); Salva & Rabhi (2010). The STS formalism offers also a large formal background (process algebra notations, definitions of implementation relations, test case generation algorithms, etc.). So, it sounds natural to use it for modelling specifications and test cases. Below, we recall the background of the STS formalism and the specification completion

An STS is a kind of input/output automaton extended with a set of variables, with guards and assignments on variables labelled on the transitions. The action set is separated with inputs beginning by ? to express the actions expected by the system, and with outputs beginning by ! to express actions produced (observed) by the system. Inputs of a system can only interact

*• V is the finite set of internal variables, while I is the finite set of external or interaction ones. We denote Dv the domain in which a variable v takes values. The internal variables are initialized with*

**Definition 1.** *A Symbolic Transition System STS is a tuple < L*, *l*0, *V*, *V*0, *I*, Λ, →*>, where:*

completion to take it into account in the test case generation.

**3. Web Service modelling in SOAP environments**

with outputs provided by the system environment and vice-versa.

*the assignment V*0*, which is assumed to take an unique value in DV,*

to take into account the SOAP environment.

*• L is the finite set of locations, with l*<sup>0</sup> *the initial one,*

**3.1 Stateful Web Service modelling**


The STS model is not specifically dedicated (restricted) to Web services. This is why we assume that an action *a*(*p*) represents either the invocation of an operation *op* which is denoted *opReq* or the return of an operation with *opResp*. Furthermore, Web service are object-oriented components which may throw exceptions. So, we also model exception messages with a particular symbol denoted !*exp* <sup>∈</sup> <sup>Λ</sup>*O*.

For simplicity and to respect the WS-basic profile, we assume that operations either always return a response or never (operations cannot be overloaded). We also assume that STSs are deterministic. As a consequence, we suppose that operations are synchronous, i.e. these ones return a response immediately or do nothing. Asynchronous methods may return a response anytime, from several states and often imply indeterminism.

An immediate STS extension is called the STS *suspension* which also expresses quiescence i.e., the absence of observation from a location. Quiescence is expressed with a new symbol !*δ* and an augmented STS denoted Δ(*STS*). For an STS S, Δ(S) is obtained by adding a self-loop labelled by !*δ* for each location where quiescence may be observed. The guard of this new transition must return true for each value of *DV*∪*<sup>I</sup>* which does not allow firing a transition labelled by an output.

Fig. 1. An STS specification

variables take the value *v*� derived from the assignment *�*(*v*, *θ*). An STS suspension Δ(S) is

A Guided Web Service Security Testing Method 201

Some behavioural properties can now be defined on STS in terms of their underlying

**Definition 3** (Runs and traces)**.** *For an STS* S*, interpreted by its LTS semantics* ||S|| =*< <sup>Q</sup>*, *<sup>q</sup>*0, <sup>∑</sup>, →*>, a run q*0*α*0...*αn*−1*qn is an alternate sequence of states and valued actions. RUN*(S) = *RUN*(||S||) *is the set of runs found in* ||S||*. RUNF*(S) *is the set of runs of* S *finished by a state in*

*It follows that a trace of a run r is defined as the projection proj*∑(*r*) *on actions. So, TracesF*(S) =

The traces of a STS suspension *TracesF*(Δ(S)) also called the suspension traces are denoted

Web services are deployed in specific environments, e.g., SOAP or REST, to structure messages in an interoperable manner and/or to manage operation invocations. Such environments may modify the observable reactions of a Web service implementation, for instance by adding and modifying the requests and responses. These modifications must be taken into account in

In this book chapter, we consider the SOAP environment only: it consists in a SOAP layer which serializes messages with XML and of SOAP receivers (SOAP processor + Web services) which is a software, in Web servers, that consumes messages (WS-I organization (2006)). The SOAP processor is a Web service framework part which represents an intermediary between client applications and Web services and which serializes/deserializes data and calls the corresponding operations. We summarize below the significant modifications involved by

• **Calling an operation which does not exist:** this action produces the receipt of a response, constructed by Soap processors, which corresponds to a Soap fault composed of the cause "the endpoint reference is not found". Soap faults are specific XML messages which give

• **Calling an existing operation with incorrect parameter types:** this action produces also the receipt of a Soap fault, constructed by the Soap processor, composed of the cause "Client". This one means that the Client request does not match the Web Service WSDL

• **Exception management:** by referring to the WS-I basic profile WS-I organization (2006), when an exception is triggered by a Web Service operation, then the exception ought to be translated into a Soap fault and sent to the Client application. However, this feature needs to be implemented by hands in the operation code. So, when the exception management is implemented, the Soap fault cause is usually equal to "SoapFaultException" (in Java or C# implementations). Otherwise, the operation crashes and the Soap processor may construct itself a Soap fault (or do nothing, depending on the chosen Web Service framework). In

testing methods to ensure that the test verdict is not falsified by the environment.

details e.g., a cause (reason) about a triggered exception or a crash,

this case, the Soap fault cause is different from "SoapFaultException".

associated to its LTS semantics suspension by ||Δ(S)|| = Δ(||S||).

*TracesF*(||S||) *is the set of traces of runs finished by states in F* ⊆ *Q.*

semantics, in particular runs and traces.

*F* ⊆ *Q.*

*STracesF*(S).

SOAP processors:

description,

**3.2 The SOAP environment**

Fig. 2. The completed specification

A specification example, is illustrated in Figure 1. This one describes, without ambiguity, a part of the Amazon Web Service devoted for e-commerce (AWSECommerceService Amazon (2009)). For simplicity, we consider only two operations: *ItemSearch* aims to search for items, and *ItemLookUp* provides more details about an item. The AWSAccessKeyID parameter uniquely identifies the user of the Web service and is provided by Amazon. The SearchIndex parameter is used to identify the item in demand. "book" is a classical value. Notice that we do not include all the parameters for readability reasons.

An STS is also associated to an LTS (Labelled Transition System) to define its semantics. Intuitively, the LTS semantics represents all the functional behaviours of a system and corresponds to a valued automaton without symbolic variables: the states are labelled by internal variable values while transitions are labelled with actions and parameter values.

**Definition 2.** *The semantics of an STS* S =*< L*, *l*0, *V*, *V*0, *I*, Λ, →*> is an LTS* ||S|| =*< Q*, *q*0, ∑, →*> where:*


$$\frac{\mathbf{1}\_l \xrightarrow{a(p), \rho, \varphi} \mathbf{1}\_j, \theta \in D\_{\rho}, \mathbf{\upsilon} \in D\_{V, \mathbf{\upsilon}} \mathbf{\upsilon}' \in D\_{V, \mathbf{\upsilon}} \rho(\mathbf{\upsilon}, \theta) \text{ true}, \mathbf{\upsilon}' = \rho(\mathbf{\upsilon}, \theta)}{(\mathbf{1}\_l, \mathbf{\upsilon}) \xrightarrow{a(p), \theta} (\mathbf{1}\_l, \mathbf{\upsilon}')} $$

This rule can be intuitively read as follows: for an STS transition *li a*(*p*),*ϕ*,*�* −−−−→ *lj*, we obtain a LTS transition (*li*, *<sup>v</sup>*) *<sup>a</sup>*(*p*),*<sup>θ</sup>* −−−→ (*lj*, *<sup>v</sup>*� ) with *v* an internal variable value set, if it exists a parameter value *θ* such that the guard *ϕ*(*v*, *θ*) is satisfied. Once the transition is executed, the internal 6 Will-be-set-by-IN-TECH

A specification example, is illustrated in Figure 1. This one describes, without ambiguity, a part of the Amazon Web Service devoted for e-commerce (AWSECommerceService Amazon (2009)). For simplicity, we consider only two operations: *ItemSearch* aims to search for items, and *ItemLookUp* provides more details about an item. The AWSAccessKeyID parameter uniquely identifies the user of the Web service and is provided by Amazon. The SearchIndex parameter is used to identify the item in demand. "book" is a classical value. Notice that we

An STS is also associated to an LTS (Labelled Transition System) to define its semantics. Intuitively, the LTS semantics represents all the functional behaviours of a system and corresponds to a valued automaton without symbolic variables: the states are labelled by internal variable values while transitions are labelled with actions and parameter values.

**Definition 2.** *The semantics of an STS* S =*< L*, *l*0, *V*, *V*0, *I*, Λ, →*> is an LTS* ||S|| =*<*

=*ρ*(*v*,*θ*)

value *θ* such that the guard *ϕ*(*v*, *θ*) is satisfied. Once the transition is executed, the internal

*a*(*p*),*ϕ*,*�*

) with *v* an internal variable value set, if it exists a parameter

−−−−→ *lj*, we obtain a

Fig. 2. The completed specification

*Q*, *q*0, ∑, →*> where:*

*li a*(*p*),*ϕ*,*�*

*• Q* = *S* × *DV is the finite set of states, • q*<sup>0</sup> = (*l*0, *V*0) *is the initial state,*

(*li*,*v*) *<sup>a</sup>*(*p*),*<sup>θ</sup>*

−−−→(*lj*,*v*�)

−−−−→*lj*,*θ*∈*Dp*,*v*∈*DV* ,*v*�

LTS transition (*li*, *<sup>v</sup>*) *<sup>a</sup>*(*p*),*<sup>θ</sup>* −−−→ (*lj*, *<sup>v</sup>*�

do not include all the parameters for readability reasons.

*•* ∑ = {(*a*(*p*), *θ*) | *a*(*p*) ∈ Λ, *θ* ∈ *Dp*} *is the set of valued symbols, •* → *is the transition relation S* × Σ × *S deduced by the following rule:*

∈*DV* ,*ϕ*(*v*,*θ*) *true*,*v*�

This rule can be intuitively read as follows: for an STS transition *li*

variables take the value *v*� derived from the assignment *�*(*v*, *θ*). An STS suspension Δ(S) is associated to its LTS semantics suspension by ||Δ(S)|| = Δ(||S||).

Some behavioural properties can now be defined on STS in terms of their underlying semantics, in particular runs and traces.

**Definition 3** (Runs and traces)**.** *For an STS* S*, interpreted by its LTS semantics* ||S|| =*< <sup>Q</sup>*, *<sup>q</sup>*0, <sup>∑</sup>, →*>, a run q*0*α*0...*αn*−1*qn is an alternate sequence of states and valued actions. RUN*(S) = *RUN*(||S||) *is the set of runs found in* ||S||*. RUNF*(S) *is the set of runs of* S *finished by a state in F* ⊆ *Q.*

*It follows that a trace of a run r is defined as the projection proj*∑(*r*) *on actions. So, TracesF*(S) = *TracesF*(||S||) *is the set of traces of runs finished by states in F* ⊆ *Q.*

The traces of a STS suspension *TracesF*(Δ(S)) also called the suspension traces are denoted *STracesF*(S).

#### **3.2 The SOAP environment**

Web services are deployed in specific environments, e.g., SOAP or REST, to structure messages in an interoperable manner and/or to manage operation invocations. Such environments may modify the observable reactions of a Web service implementation, for instance by adding and modifying the requests and responses. These modifications must be taken into account in testing methods to ensure that the test verdict is not falsified by the environment.

In this book chapter, we consider the SOAP environment only: it consists in a SOAP layer which serializes messages with XML and of SOAP receivers (SOAP processor + Web services) which is a software, in Web servers, that consumes messages (WS-I organization (2006)). The SOAP processor is a Web service framework part which represents an intermediary between client applications and Web services and which serializes/deserializes data and calls the corresponding operations. We summarize below the significant modifications involved by SOAP processors:


Symb Message Guard Update

A Guided Web Service Security Testing Method 203

!d1 !soapfault(c) [c�="Client" ∧ c�="the endpoint..."] !d2 !soapfault(c) [c=="Client" ∨ c=="the

!ftp !soapfault(c) [c=="SOAPFaultException"]

[isvalid==false ∨ id<>"ID"]

endpoint..."]

Security policies are more and more expressed by means of formal languages to express without ambiguity concepts such as obligation, permission or prohibition for an organization. A natural way to test policies consists in deriving, manually or semi-automatically, test cases directly from the latter. Usually, we obtain abstract tests, that we call *test patterns*. Some works Mouelhi et al. (2008) have proposed solutions to derive test patterns from basic security rules. In this Section, to illustrate our methodology and to experiment existing Web services, we propose to formalize some test patterns from the recommendations provided by the OWASP organization OWASP (2003). Thereby, these test patters are specialized for Web services and will help to detect attacks/vulnerabilities such as empty passwords, brute force attack, etc. They are related to the following criteria: availability, authentication and authorization. We do not provide an exhaustive test pattern list, because this one depends firstly of the security policy established by an organization and because an exhaustive list would deserve a separate book of its own. Nevertheless, the following test patterns cover most of the OWASP recommendations. These test patterns are constructed over a set of attacks (brute force, SQL injection, etc.) and model how a Web service should behave when it receives one of them. As stated previously, we have chosen to formalize test patterns with the Nomad language. Nomad is based upon a temporal logic, extended with alethic and deontic modalities. It can easily express the obligation, the prohibition and the permission for atomic or non-atomic actions with eventually timed constraints. Bellow, we recall a part of the Nomad grammar. The complete definition of the Nomad language can be found in Cuppens et al. (2005).

[id==ID ∧ req==reqid]

[isvalid==true ∧ id=="ID"] reqid:=req

[isvalid==true] itemsReq:= items

TestDom:={Spec( ItemSearch);RV;Inj}

?a ?ItemSearchReq(AWSAccessKeyID id,SearchIndex s, KeyWords k) ?atp ?ItemSearchReq(AWSAccessKeyID id,SearchIndex s, KeyWords k)

!b1 !ItemSearchResp(String[] errors, String

!b2 !ItemSearchResp(String[] items, String

?c ?ItemLookUpReq(AWSAccessKey ID

?g ?ItemLookUpReq(AWSAccessKey ID

!h1 !ItemLookUpResp(String[] items,

!h2 !soapfault(c) [isvalid�=true]

isvalid)

req, String isvalid)

id, RequestID req)

id, RequestID req)

String isvalid)

**4. Nomad test patterns**

Fig. 3. Symbol table

In summary, SOAP processors add new messages, called SOAP faults, which give details about faults raised in the server side. They return SOAP faults composed of the causes "Client" or "the endpoint reference not found" if services or operations or parameter types do not exit. SOAP processors also generate SOAP faults when a service instance has crashed while triggering exceptions. In this case, the fault cause is equal to the exception name. However, exceptions correctly managed in the specification and in the service code (with try...catch blocks) are distinguished from the previous ones since a correct exception handling produces SOAP faults composed of the cause "SOAPFaultException". Consequently, it is manifest that SOAP modifies the behaviour of the specification by adding new reactions which must be taken into account while testing.

So, we propose to augment an initial specification with the SOAP faults generated by SOAP processors. We denote !*soapf ault*(*cause*) a SOAP fault where the external variable *cause* is the reason of the SOAP fault receipt.

Let S =*< L*S, *l*0S, *V*S, *V*0S, *I*S, ΛS, →S*>* be an STS and Δ(S) be its suspension. Δ(S) is completed by means of the STS operation *addsoap* in Δ(S) which augments the specification with SOAP faults as described previously. The result is an STS S↑. The operation *addsoap* is defined as follow: *addsoap* in Δ(S) =*def S*<sup>↑</sup> =*< L*S<sup>↑</sup> , *l*0S, *V*S, *V*0S, *I*S<sup>↑</sup> , ΛS<sup>↑</sup> , →S↑*>* where *L*S<sup>↑</sup> , *I*S<sup>↑</sup> , ΛS<sup>↑</sup> and →S<sup>↑</sup> are defined by the following rules:

Exception to Soapfault: *l*1 !*exp*,*ϕ*,*�* −−−−→Δ(S)*l*<sup>2</sup> *l*1 !*soapf ault*(*c*),*ϕ*,*�* −−−−−−−−−→<sup>S</sup><sup>↑</sup> *<sup>l</sup>*<sup>2</sup>

Input

$$\begin{array}{lcl} \text{Completion:} & l\_{1} \xrightarrow{\gamma\_{\text{pop}} \text{Pop}(p), \rho\_{\text{el}}} & l\_{\Delta} \mathrel{\mathop{:}} \text{Pos}\_{1} \xrightarrow{\gamma\_{\text{pop}} \text{Pos}\_{1} \{p\}, \rho', \rho'\}} & l \not\leq \underset{\Delta(\text{S})}{\longrightarrow} \text{No}\_{\Delta(\text{S})} \xrightarrow{\gamma\_{\text{D}} \text{Pos}\_{1} \{p\}, \rho'\}} & l \not\leq \underset{\Delta(\text{S})}{\longrightarrow} \text{No}\_{\Delta(\text{S})} \downarrow \text{P} \not\leq \underset{\Delta(\text{S})}{\Delta(\text{S})} \\\\ & l \xrightarrow{\gamma\_{\text{pop}} \text{Pos}(p), \rho, \rho} \underset{\Delta(\text{S})}{\longrightarrow} \text{It}\_{\Delta(\text{S})} \text{ if } \rho' = \bigwedge\_{\begin{subarray}{c} \text{top} \& \text{Top}(p) \text{Ass}(\text{S}) \\ \text{( $\Delta(\text{S})$  is odd)} \end{subarray}} & l \not\leq \underset{\Delta(\text{S})}{\longrightarrow} \text{top} \end{array}$$
  $\text{SOAP} \text{fault} \qquad \begin{array}{l} l \vdash \frac{\text{top} \; \text{Top}(p) \text{Ass}(\text{S})}{\longrightarrow} \text{s}\_{1} \downarrow \longrightarrow} \text{1} \end{array}$ 

The first rule translates an exception message into a SOAPfault. The second one completes the specification to be input enabled. Indeed, it is stated, in the WS-I basic profile WS-I organization (2006), that any Web service operation can be invoked anytime. So, we assume that each unspecified operation request should return a SOAP fault message. The last rule completes the output set by adding, after each transition modelling an operation request, a transition labelled by a SOAP fault. Its guard corresponds to the negation of the guards of transitions modelling responses. This transition refers to the exception management. When any exception is triggered in the server side, a SOAP fault is sent.

A completed specification example is illustrated in Figure 2 where the solid red transitions represent the operation call completion and the dashed ones the SOAP fault completion. The symbol table is given in Figure 3. For instance, the transition from location 4 labelled by !h2 is added to express that after calling the operation *ItemLookUp* a SOAP fault may be received.

8 Will-be-set-by-IN-TECH

In summary, SOAP processors add new messages, called SOAP faults, which give details about faults raised in the server side. They return SOAP faults composed of the causes "Client" or "the endpoint reference not found" if services or operations or parameter types do not exit. SOAP processors also generate SOAP faults when a service instance has crashed while triggering exceptions. In this case, the fault cause is equal to the exception name. However, exceptions correctly managed in the specification and in the service code (with try...catch blocks) are distinguished from the previous ones since a correct exception handling produces SOAP faults composed of the cause "SOAPFaultException". Consequently, it is manifest that SOAP modifies the behaviour of the specification by adding new reactions which must be

So, we propose to augment an initial specification with the SOAP faults generated by SOAP processors. We denote !*soapf ault*(*cause*) a SOAP fault where the external variable *cause* is the

Let S =*< L*S, *l*0S, *V*S, *V*0S, *I*S, ΛS, →S*>* be an STS and Δ(S) be its suspension. Δ(S) is completed by means of the STS operation *addsoap* in Δ(S) which augments the specification with SOAP faults as described previously. The result is an STS S↑. The operation *addsoap* is defined as follow: *addsoap* in Δ(S) =*def S*<sup>↑</sup> =*< L*S<sup>↑</sup> , *l*0S, *V*S, *V*0S, *I*S<sup>↑</sup> , ΛS<sup>↑</sup> , →S↑*>* where *L*S<sup>↑</sup> ,

?*opiReq*(*p*),*ϕ*�,*�*�

*<sup>l</sup>*� !*opiResp*(*p*),*ϕ*,*�* −−−−−−−−→Δ(S)*l*��

The first rule translates an exception message into a SOAPfault. The second one completes the specification to be input enabled. Indeed, it is stated, in the WS-I basic profile WS-I organization (2006), that any Web service operation can be invoked anytime. So, we assume that each unspecified operation request should return a SOAP fault message. The last rule completes the output set by adding, after each transition modelling an operation request, a transition labelled by a SOAP fault. Its guard corresponds to the negation of the guards of transitions modelling responses. This transition refers to the exception management. When

A completed specification example is illustrated in Figure 2 where the solid red transitions represent the operation call completion and the dashed ones the SOAP fault completion. The symbol table is given in Figure 3. For instance, the transition from location 4 labelled by !h2 is added to express that after calling the operation *ItemLookUp* a SOAP fault may be received.

−−−−−−−−−→*l*∈→/ <sup>Δ</sup>(S),?*opReqi*∈Λ*<sup>I</sup>*

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→<sup>S</sup><sup>↑</sup> *<sup>l</sup>*<sup>1</sup>

¬*ϕ*

,*l*� !*soapf ault*(*c*)),*ϕ*=[*c*�="*CLIENT*"∧*c*�="*the endpoint*..."],<sup>∅</sup>

<sup>Δ</sup>(S),*l* � ∈/*L*Δ(S)

taken into account while testing.

reason of the SOAP fault receipt.

Exception to Soapfault:

Input

completion:

SOAPfault completion:

*I*S<sup>↑</sup> , ΛS<sup>↑</sup> and →S<sup>↑</sup> are defined by the following rules:

!*soapf ault*(*c*),*ϕ*,*�* −−−−−−−−−→<sup>S</sup><sup>↑</sup> *<sup>l</sup>*<sup>2</sup>

?*opiReq*(*p*),∅,∅ −−−−−−−−→<sup>S</sup><sup>↑</sup> *<sup>l</sup>*�

?*opReq*(*p*),*ϕ*,*�* −−−−−−−−→Δ(S)*l*2,*l*<sup>1</sup>

> � ,*ϕ*� =

any exception is triggered in the server side, a SOAP fault is sent.

*<sup>l</sup>*� !*soapf ault*(*c*),*ϕ*�,<sup>∅</sup> −−−−−−−−−−→<sup>S</sup><sup>↑</sup> *<sup>l</sup>*

*l*1 !*exp*,*ϕ*,*�* −−−−→Δ(S)*l*<sup>2</sup>

*l*1

*<sup>l</sup>* ?*opReq*(*p*),*ϕ*,*�* −−−−−−−−→Δ(S)*<sup>l</sup>*

*l*1

*l*1


Fig. 3. Symbol table
