.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
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><!--
</password><role>user</role><mail>
--><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.
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
Generated XML Messages
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
Generated XML Messages
Back-end Systems
System 1
System 2
System n
SUT
11
Proposed Approach: Search-based Testing (SBT)
Front-endSystem
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
• 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
Generated XML Messages
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
Front-endSystem(SUT)
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
Front-endSystem(SUT)
Test Case Generator
Test Case 2
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