ICST 2017 presentation

1. .lusoftware verification & validation
VVS
A Search-based Testing Approach for XML
Injection Vulnerabilities in Web Applications
Sadeeq Jan, Cu D. Nguyen, Andrea Arcuri, Lionel Briand
SnT, University of Luxembourg,
Luxembourg
ICST2017
10th IEEE International Conference on Software Testing, Verification and Validation
13-17 March 2017, Tokyo,Japan

2. Background & Context
2

3. 3
• Bypassing authentication
• Privilege escalation
• Information disclosure
• Generating errors/system crash
Impact
Definition
Injecting malicious content into XML files/messages to manipulate
or compromise the logic of an application or service
XML Injection

4. 4
Example: Web Application for User
Registration with XML Database
Create new account
<user>
<username>Tom</username>
<password>m1U9q10</password>
<role>user</role>
<mail>a@b.com</mail>
</user>
<user>
<username>admin</username>
<password>s4n3p81</password>
<role>Administrator</role>
<mail>sv-admin@gmail.com</mail>
</user>
…..
......
<user>
<username>Tom</username>
<password>m1U9q10</password>
<role>user</role>
<mail>a@b.com</mail>
</user>
XML
Database

5. <user>
<username>Tom</username>
<password>m1U9q10</password>
<!--
</password>
<role>user</role>
<mail>
-->
<role>Administrator</role>
<mail>a@b.com</mail>
</user>
Web Form
Generated XML Message
Well-formed and valid
--><role>Administrator<role><mail>a@b.com
m1U9q10</password><!--
5
XML Injection Example
(Privilege Escalation)
Malicious strings for SQL injection or Cross-site scripting can also be used here.

6. Approach
6

7. Testing Focus
Front-end
System
XML
I1
I2
In
Generated XML
Messages
Back-end
Systems
System 1
System 2
System n
7
XML based Systems

8. • 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-end
System
XML
I1
I2
In
Generated XML
Messages
Back-end
Systems
System 1
System 2
System n

9. 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. 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-end
System
XML
I1
I2
In
Generated XML
Messages
Back-end
Systems
System 1
System 2
System n

11. SUT
11
Proposed Approach:
Search-based Testing (SBT)
Front-end
System
XML
I1
I2
In
Generated XML
Messages
Back-end
Systems
System 1
System 2
System n
Search input space to generate malicious XML output,
if possible

12. • 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-end
System
Why SBT Approach for XML Injections?
12

13. Select * from Users where UserName = 'Mike' and
Passwrd = '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

14. SBT Approach for XML Injection
14
Test Objectives
(malicious XML messages)
TO1 TO2 TOn
XML XML XML
I1
I2
In
Front-end
System
(SUT)
XML
Generated XML
Messages
Test Case
Generator
Fitness
Function
Genetic Algorithm
String Edit Distance (Levenshtein distance)

15. <user>
<username>Tom</username>
<password>m1U9q10</password>
<role>user</role>
<mail>a</mail>
<role>Administrator</role>
<mail>tom@uni.lu</mail>
</user>
Test Objective (TO)
I1à username: Tom
I2à password: m1U9q10
I3à Email: “role=Adm”+tom@uni.lu
<user>
<username>Tom</username>
<password>m1U9q10</password>
<role>user</role>
<mail>role=Adm+
tom@uni.lu</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 Case1
15
I1
I2
In
Front-end
System
(SUT)
Test Case
Generator

16. <user>
<username>Tom</username>
<password>m1U9q10</password>
<role>user</role>
<mail>a</mail>
<role>Administrator</role>
<mail>tom@uni.lu</mail>
</user>
Test Objective (TO)
I1à username: Tom
I2à password: m1U9q10
I3à Email: <role>Administrator</peho>tom@uni.lu
<user>
<username>Tom</username>
<password>m1U9q10</password>
<role>user</role>
<mail> <role>Administrator<role>
<peho>tom@uni.lu </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
Front-end
System
(SUT)
Test Case
Generator
Test Case2

17. Evaluation & Results
17

18. 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

19. 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. 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

21. 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.

22. 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

23. 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

24. • 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

25. Summary
25