Vulnerability Testing of HTTP based on Vulnerability-testing Oriented Petri Net (VOPN)

Vulnerability Testing of HTTP

based on Vulnerability-testing

Ori-ented Petri Net (VOPN)

Li Weihai

1,2

, Ma Yan

1,2

, Huang Xiaohong

1 1

Research Institute of Networking Technology, Beijing Key Laboratory of Intelligent Telecommunications Software and Multimedia, Beijing, P.R.China

2

School of Electronic Engineering, Beijing University of Posts and Telecommunications, Beijing, P.R.China

Abstract: Vulnerability-testing Oriented Petri Net (VOPN), a vulnerability testing model for

commu-nication protocol is brought forward first, which is

combined Petri Net system with protocol Syntax analysis. Then vulnerability testing of implemen-tation of HTTP protocol based on VOPN is made and the process is analyzed to prove the feasibility of the model.

Key words: vulnerability testing; testing model; HTTP; Petri net

I. INtroduCtIoN

In computer network and protocol engineering, protocol testing has become the most active

re-search field. Robustness testing and Interoperabil -ity testing are the important part of the protocol testing. And Robustness testing consists of per-formance testing and security testing[1]. The vul-nerability testing, which is also an important kind

of Robustness testing is made to find the weakness

in a protocol implementation that allows an at-tacker to violate the integrity of the system in the

Collecting of vulnerability of a protocol imple-mentation is very important, but unfortunately in vulnerability testing, the disclosure and fixing of vulnerabilities are expensive and inconvenient[2]. This paper introduces a systematic approach of vulnerability testing, brings up a model which combines Petri net and syntax analysis in vulnera-bility analysis. Then vulneravulnera-bility testing of imple-mentation of HTTP (Hyper Text Transfer Protocol) is made and the process is introduced in detail.

II. syNtax testINg aNd Its

exteN-sIoN

Syntax testing is a kind of method for finding pos -sible weakness in protocol implementation. In syntax testing, the test-cases, i.e. the input to the

software, are created based on the specifications of

protocols realized by the interfaces of software[3]. Interfaces have many formats: command-line

prompts, files, environment variables, pipes, sock

-ets, etc. An interface has a specification which de

or open. The motivation for testing based on the syntax analysis of this interface definition lan-guage springs from the fact that each interface has

a specification, whether its meaning was hidden or

open, from which effective vulnerability test cases can be created with a relatively small effort[3].

To find weakness in protocol implementation, fault injection is the main method to execute test in syntax testing. The selection of test cases could be single-error sentences, also could be proceed to pairs of errors, three errors combination, and so on. There are at least five kinds of error that can be produced in syntax analysis, which are Syntax error, Delimiter error, Field-value errors, Context-dependent errors, State dependency error[3].

Although having the advantages of low cost and high reliability, syntax testing has these shortcom-ings:

a) Only the error in the implementation level can be detected by syntax testing.

b) Not all of the part of the software can be de-tected, for there is no limit for errors.

And because syntax testing focuses on protocol specifications analysis, it has the shortcoming in protocol analysis, especially in the state transition analysis. On the other hand, as a good protocol analysis tool, there are many new kinds of Petri net and it plays a more and more important role in pro-tocol vulnerability analysis. The paper[4] brought an advanced Petri net for protocol conformance testing. But due to many differences between con-formance testing and vulnerability testing, such as different perspectives, having or not having redun-dant element, this advanced Petri Net and many other similar kinds of Petri Net can’t be directly used in vulnerability testing.

To take advantage of Petri net in protocol state analysis, a new extended syntax testing method called VOPN (Vulnerability-testing Oriented Petri Net), which combined Petri net and syntax test-ing is brought forward here. It can compensate for lacking of protocol analysis in the former syntax testing method.

III. model of exteNded syNtax

aNalysIs

3.1 Method flow

The flow of the VOPN consists of three steps: VOPN Modeling, VOPN Analysis, and Fault in-jection (test cases running), which is explained in Figure 1. VOPN Modeling means to construct an extended Petri net model based on the text de-scription of protocol to be tested. After this step, a VOPN of protocol was constructed; VOPN Analy-sis means to analyze the Petri net and design test cases from it; Fault Injection means to put data or message in test cases into the system under test (SUT), and to create the test report.

Fig.1 Flow of the VOPN

Protocol Description VOPN Constructing VOPN Model VOPN Analysis Fault Injection(Test cases running) Test cases input output Test Report input input output output Documents Steps 3.2 VOPN constructing

In the stage of VOPN Constructing, e.g. Protocol Modeling, an extended Petri net was constructed according to the text protocol description. The

VOPN was defined below.

3.2.1 The static structure of VOPN.

Definition 1: The extended Petri net for vulner-ability testing has eight members. PS=(P, T; F, A,

X, C, t, M0). 1) (P, T; F)is essential Petri net. P is place. T is transition. F is flow. 2) A is a non-empty limited set of resource. Resource can be variable,

const or timer; 3) X is a limited set of fault,

con-sisting of all possible types of fault, it must cling

to A, and the element relation between A and X is

injected into SUT, it may have many

correspond-ing “x” in X, which was denoted as “a(x)”. 4)C is

resource function, C:P

U

T→P(A), P(A) is power

set of resource set A. 5) Transition set T = Ts

U

Tr

U

Tt, and Ts∩Tr∩Tt= ∅, Ts is sending transition, de-note sending operation, Tt is receiving transition,

denote receiving operation transition, and Tt is

timeout transition. 6) t is timeout function, t: Tt→0

U

N+ , N+ denote positive rational number. 7) M0 is

initialization identifier, M0:P→AMS.

Explanation of Definition 1:1) This VOPN is based on the essential Petri net. 2) When modeling the protocol, the resource set A in company with fault set X describe all the input data, timer data and fault data that would be injected into SUT. 3)

Resource function C defines the resource that be

-longs to every position pi

∈

P and every transition ti

∈

T. For pi

∈

P, C(pi) means the resource set belong

to it. For ti

∈

T, C(ti) means all the resources that the transition needed, which is the necessary

con-dition for the transition. 4) Transition set T denotes

communication operation or timeout event. State of SUT will change when these events happen. 5)

t defines the time limit of each timeout. 6) M0 de-notes the initialization state of the system.

3.2.2 Dynamic behavior

A VOPN model’s dynamic behavior regulated by these rules: 1) If all the input positions of send transitions have at least a token, then this transi-tion can take place. 2) If all of the input positransi-tion of receive transitions have at least a token, and the received resource is equal to the resource which belongs to the transition, then these transitions can take place. 3) If all the input position belong to a timeout transition have at least one token, and the time is beyond the limit, the timeout transition can take place.

3.2.3 Denotation method

The figure and table denote the model for VOPN.

In the figure of VOPN, symbol based on that of Petri net was used to denote the dynamic behavior of protocol. Broken line denotes fault injection. Ta-bles in VOPN explain the meaning of resource and

place, transition, resource, and fault. In the exam-ple in Figure 2, a client that in initialization state

(s0) transfers to the state of waiting for connection

(s1) by sending a connect request. The broken line

denotes that the resource a0 was injected fault of x0 in sending transition. The client should keep stay-ing at the initialization state and discard the fault connection request.

3.3 VOPN analysis

After the construction of the VOPN, test cases could be got from the analysis of the model. In VOPN, the symbols that denote the state and the transition are the same to that in the essential Petri net. The element T denotes transition and the re-source function denotes the rere-source related to

transition. The element S denotes place, and place

that has one or more states. Vulnerability X denotes

types of all possible errors. The analysis rules were explained below.

Seeking all transitions that describe

communica-tion. This type of transition is potential fault

injec-tion point. In Figure 2, t1 denotes the client

commu-nicates with the server by sending a request to it.

Choosing of fault type. Theset of vulnerability

defines the fault that could be injected into SUT. In syntax testing, there are five types of faults. Each

place could be injected one or multiple fault. By the increasing of types of fault, the number of test cases will increase at exponential level.

Expanding of table. Resource, fault type could be added continuously, and then numbers of test cases will increase. Thus the test will be more ex-haustive.

3.4 Fault injection

In the step of fault injection, the test case which generated in the stage of model analysis would be executed by a “fault injector”. The “fault injector”

a0(x0) S0

a0

t1 S1

other protocols, checks the result, and then gener-ates the test report.

Iv. testINg of Http

With the number of internet user increasing rapidly, and HTTP widely used[5], it is necessary to guar-antee the robustness of HTTP client. Here the vul-nerability testing of HTTP is brought. Figure 3 is a model of HTTP, and Table 1~4 describe the place, transition, resource and vulnerability of HTTP.

According to the description of the protocol, the client of HTTP has four states, including No connection, Connected, Waiting for response, Re-sponse waiting close. These four states were

denot-ed by four symbols from S0 to S3. In the state of No

connection, the client transfers to Connected state by receiving request. In the state of connected, if the client sends the HTTP request according to the user action, it will transfer to the state of Waiting for response. These responses of the HTTP server trigger the transition if client state, so they could be denoted by transition. Table 2 explains the meaning of the transitions.

t0 s1 s2 s3 t1 t2 t3 a 0 (x 1₎ a 3 (x 0_{, x} 1₎ s0

Fig.3 VOPN of HTTP Client

Places meanings

S0 No connection

S1 Connected

S2 Waiting for response

S3 Response waiting close

Table 1 Places of HTTP Transitions meanings t0 Send connect.req t1 Infomation.req t2 Send/receive response t3 Close connection Table 2 Transitions of HTTP

Name type place meaning

a0 a1 a2 a3 a4 a5 Version URI Time Char set Rep. line State line s0,s1,s2,s3, s0,s1,s2,s3 s0,s1,s2,s3 s0,s1,s2,s3 s0,s1,s3 s2 HTTP version URI=“http:”“//”“hostname”.. Greenwich Time UTF-8 or GBK Request line in Request Msg. State line in Response Msg.

Table 3 Example Resources of HTTP

After the construction of the model, test cases can be got from the analysis of the model. In vul-nerability testing, the fault injection was used to test the robustness of SUT. So adding fault in com-pany with the sending transition and the resource can compose a test case. In Figure 3, a fault was

injected into the transition of t1, which was denoted

by broken lines. And at the side of the broken line, the fault resource and the fault type were labeled. The label for the fault is a0(x1), with a0 explained

in Table 3, and x1 explained in Table 4. This fault

is a CharString error injected into the URL in re-direct request. The error message is: GET /test.htm HTTPxx1.1xxxxxxxxxxxxxxxxxxx

In the fault injection stage, all the test cases were sent by UDP to the HTTP client. If the mes-sage sent is correct, the client way will transmit to the state of Waiting for response. If the Client re-ceived a wrong message it will reject the response and send back the corresponding message, while avoiding transmitting the wrong message to the

type

x0 Delimiter errors Using other special sy

substitute Delim

x1 Char String errors Using other special string to

substitute common string ngth char

x1 Length errors Using wrong le

string in message

Table 4 Fault of HTTP symbol m eaning

mbol to iter in

References

[1] DeVale J, Koopman P, Guttendorf D, The Ballista Soft-ware Robustness Testing Service, Testing Computer SoftSoft-ware Conference, 1999.

[2] Laakso M., Takanen A., Röning J.(1999). The Vulnerabil-ity Process: a tiger team approach to resolving vulnerabilVulnerabil-ity cases[EB/OL]. In proceedings of the 11th FIRST Conference on Computer Security Incident Handling and Response, Bris-bane. 13-18 June, 1999.

[3] Rauli Kaksonen, Marko Laakso, Ari Takanen. (2000). Vul-nerability Analysis of Software through Syntax Testing [EB/ OL]. [http://www.ee.oulu.fi/research/ouspg/protos/analysis/ WP2000-robustness/]

[4] Xiao Zheng, Feng Qin, (2006). Auto Generation of Test

Case Based On Petri Net.Journal Of Central China Science

University. 2006 3(4).

[5] IETF. RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1. http://www.faqs.org/rfcs/rfc2616.html.

Biographies

Li Weihai received his master degree of computer science from Beijing University of Posts & Telecommunication in 2004. He is now a Lecturer in School of Electronic Engineer-ing in BUPT. His current research interests are protocol test-ing of computer networks.

Prof. Ma Yan, Vice President of Network Information Center, doctoral supervisor in Computer Science and Technology Department and . His research includes network management technology in TCP/IP network, network security, mobile IP,

IPv6, etc.

Dr. Huang Xiaohong received her Ph.D degree from the school of Electrical and Electronic Engineering (EEE), Nan-yang Technological University, Singapore in 2005. Since 2005, Dr. Huang is currently the Associate Professor in the Research Institute of Network Technology at BUPT. She has published more than 30 academic papers in the area of WDM optical networks, IP networks, Grid computing and other rel-evant fields. Her current research interests are performance analysis of computer networks, QoS management, service

classification, grid computing etc.

http server.

Three type of fault were mostly used in the test-ing account for the characteristic HTTP:

Char string abnormity: The abnormal char string consists of chars ASCII. In this example, we test many char numbers that can cause error.

Length abnormity: Length abnormity means us-ing integer of type of UINTVAR.

Delimiter errors: Delimiter errors means puting wrong URL delimiter such as (;@//”,”:+1000x”/) into string to test the URL parser.

v. result of testINg

We use the method of VOPN to test the open source HTTP client Maxthon2.1.5. For the 500 test cases, the Maxthon failed in 23. Among them, there are 0 length abnormity error, 13 Char string errors and 10 Delimiter errors, Every failure means a vulnerability that may be attacked by some meth-ods, such as DOS. Mostly these failures may be

caused by memory leak, stack overflow, or cache overflow.

Of course, these test cases cannot find all of the

possible vulnerability, and if time permits more and more test cases can be produced. Although it is believe that these test cases can cover all the tran-sition, we hope more test cases and more elaborate model can be constructed to testing. Further works of VOPN may be computing of fault cover rate, simplification of the model, and test case

auto-generation.

Acknowledgments

Specific thanks to Gang Liu, Bin Hou, Qing Ma, and Xing Zhao’s help of completing the programme. Thanks also to Qiong Sun’s advice for improving the paper. Finally, we ac-knowledge the valuable feedback provided by the anonymous reviewers and our colleagues at Beijing University of Posts & Telecommunication.