a search-based testing approach for xml injection vulnerabilities in web applications

.lusoftware verification & validationVVS

A Search-based Testing Approach for XML Injection Vulnerabilities in Web Applications

Sadeeq Jan, Cu D. Nguyen, Andrea Arcuri, Lionel BriandSnT, University of Luxembourg,

Luxembourg

ICST201710th IEEE International Conference on Software Testing, Verification and Validation

13-17 March 2017, Tokyo, Japan

Background & Context

2

3

• Bypassing authentication• Privilege escalation• Information disclosure• Generating errors/system crash

Impact

Definition

Injecting malicious content into XML files/messages to manipulateor compromise the logic of an application or service

XML Injection

4

Example: Web Application for User Registration with XML Database

Create new account

<user><username>Tom</username> <password>m1U9q10</password><role>user</role><mail>[email protected]</mail>

</user>

<user><username>admin</username> <password>s4n3p81</password><role>Administrator</role><mail>[email protected]</mail>

</user>…........<user>

<username>Tom</username> <password>m1U9q10</password><role>user</role><mail>[email protected]</mail>

</user>

XML Database

<user><username>Tom</username> <password>m1U9q10</password><role>Administrator</role><mail>[email protected]</mail>

</user>

Web FormGenerated XML MessageWell-formed and valid

--><role>Administrator<role><mail>[email protected]

m1U9q10</password><!--

5

XML Injection Example(Privilege Escalation)

Malicious strings for SQL injection or Cross-site scripting can also be used here.

Approach

6

Testing Focus

Front-endSystem

XML

I1

I2

In

Generated XML Messages

Back-end Systems

System 1

System 2

System n

7

XML based Systems

• Is the front-end system (SUT) vulnerable to XML Injections?

• Step 1: Create/obtain a set of malicious XML messages

8

How to test the front-end system?

Front-endSystem

XML

I1

I2

In


Back-end Systems

System 1

System 2

System n

9

An example of a malicious XML message created with SOLMI tool

SOLMI

Generation of Malicious XML Messages • Automatically generating malicious XML messages for different types of

XML Injection

• Addressed by our tool SOLMI (ISSTA'16)

10

How to test the front-end system?• Is the front-end system (SUT) vulnerable to XML Injections?

• Step 2: Search for inputs that can result in one of the malicious XML messages (TO)

• If such inputs exist, the front-end system is vulnerable, i.e., testing for TO coverage

Front-endSystem

XML

I1

I2

In


Back-end Systems

System 1

System 2

System n

SUT

11

Proposed Approach: Search-based Testing (SBT)

Front-endSystem

XML

I1

I2

In


Back-end Systems

System 1

System 2

System n

Search input space to generate malicious XML output, if possible

• Input space is very large (all possible values of I1, I2…In)

• Front-end system à Black-box

• Adapted when source code is not available (e.g., external penetration testing)

XML

I1

I2

In

Front-endSystem

Why SBT Approach for XML Injections?

12

Select * from Users where UserName = 'Mike' andPasswrd = 'abc' OR '1'='1'

Unknown input-output transformations

13

Rejects inputs containing malicious characters e.g., <,

Converts malicious input to valid ones e.g., delete any text between < and >

Domain specific transformation e.g., JSON to XML, calculating age from DOB etc.

Passwrd: abc' O<script>R <script>'1'='1

Passwrd: abc' <script…..> abc'abc' OR '1'='1

Validation

Sanitisation

Other transformations

SBT Approach for XML Injection

14

Test Objectives(malicious XML messages)

TO1 TO2 TOnXML XML XML

I1

I2

In

Front-endSystem(SUT)

XML


Test Case Generator

Fitness Function

Genetic Algorithm

String Edit Distance (Levenshtein distance)

<user><username>Tom</username> <password>m1U9q10</password><role>user</role><mail>a</mail><role>Administrator</role><mail>[email protected]</mail>

</user>

Test Objective (TO)

I1à username: TomI2à password: m1U9q10I3à Email: “role=Adm”[email protected]

<user><username>Tom</username> <password>m1U9q10</password><role>user</role><mail>role=Adm+ [email protected]</mail>

</user>

Generated XML

Fitness Function (d)-Distance between the output XML message and the TO

d1=20

Test Generation & Fitness Function (dt-o)

Goal: Minimize d (0 is ideal)

Test Case 1

15

I1

I2

In


Test Case Generator

<user><username>Tom</username> <password>m1U9q10</password><role>user</role><mail>a</mail><role>Administrator</role><mail>[email protected]</mail>

</user>

Test Objective (TO)

I1à username: TomI2à password: m1U9q10I3à Email: <role>Administrator</peho>[email protected]

<user><username>Tom</username> <password>m1U9q10</password><role>user</role><mail> <role>Administrator<role> <peho>[email protected] </mail>

</user>

Generated XML

d2=10

Test Generation & Fitness Function (dt-o)

Goal: Minimize d (0 is ideal)

d2 < d1(Test Case 2 is better Test Case 1)

Fitness Function (d)-Distance between the output XML message and the TO

16

I1

I2

In


Test Case Generator

Test Case 2

Evaluation & Results

17

Research Questions

To what extent is our search-based approach effective in detecting XMLi vulnerabilities?

How does our search-based approach perform compared to random search?

18

RQ1: Effectiveness

RQ2: Comparison with random search

What is the cost, in terms of execution time, of applying the proposed approach?

RQ3: Efficiency

Additional RQs

• Impact of input validation (RQ4)

• Impact of the number of input parameters (RQ5)

• Impact of input alphabet size (RQ6)

• Using all ASCII characters vs only those present in TOs

19

20

• Insecure Front-end for Bank Card Processing System (SBANK)• Secure Front-end for Bank Card Processing System (SSBANK)

Study 1: RQs 1 to 6

• Open Source Web App (XMLMAO)• Industrial Application (M)

Study 2: RQs 1 to 3

Subjects

Summary of Results

21

Application TO Coverage(SBT)

TO Coverage(Random Search)

Avg. Exec time per TO(min-max) in mins

SBANK(Insecure) 98/98 (100%) 0 10-31

SSBANK(Secure) 36/98 (36.73%) 0 11-25

XMLMao(open source) 24/24 (100%) 0 5-7

M(Industrial App) 1/4 (25 %) 0 32

Note: Each experiment was repeated 10 Times to account for randomness.

The proposed SBT approach is highly effective in searching for inputs to detect XML Injection vulnerabilities, when they

exist.

Random Search could not cover a single TO in any experiment, while the proposed approach covered all possible

TOs.

22

RQ1: Effectiveness

RQ2: Comparison with random search

Answers to RQs

The average execution time ranges from 5 to 32 minutes per TO, which is acceptable in practice.

RQ3: Efficiency

Input validation adversely affects the TO coverage.

23

RQ4: Impact of input validation

Answers to Additional RQs

Increasing the number of input parameters makes the search harder.

Using restricted alphabet makes the search easier.

RQ6: Impact of input alphabet size

RQ5: Impact of the number of input parameters

• A novel search-based testing approach for the detection of XML Injections

• Extensive evaluation of the approach• Highly effective in searching for inputs to detect

XML Injection vulnerabilities• Random search does not work at all• Generalizable to other types of attacks

Conclusion

24

Summary

25