For this purpose, we did regression testing using Selenium (Selenium, 2014), a frame- work for testing web applications. Selenium automates browsing, and verifies the results of the requests sent to web applications. The DVWA 1.0.7 application and the samples in SA- MATE were tested because they contain a variety of vulnerabilities detected and corrected by the WAP tool (see Table3.16). Specifically, WAP corrected 6 files of DVWA 1.0.7, and 10 of SAMATE.
The regression testing was carried out in the following way. First, we created in Sele- nium a set of test cases with benign inputs. Then, we ran these test cases with the original DVWA and SAMATE files, and observed that they passed all tests. Next, we replaced the 16 vulnerable files by the 16 files returned by WAP, and reran the tests to verify the changes introduced by the tool. The applications passed again all the tests.
3.7
Conclusions
This chapter presents an approach for finding and correcting input validation vulnerabilities in web applications, and a tool that implements the approach for PHP programs and input validation vulnerabilities. The approach and the tool search for vulnerabilities using a com- bination of two techniques: static source code analysis and data mining. Data mining is used to identify false positives using 3 machine learning classifiers. All classifiers were selected after a thorough comparison of several alternatives. It is important to note that this com- bination of detection techniques cannot provide entirely correct results. The static analysis problem is undecidable, and resorting to data mining cannot circumvent this undecidability, but only provide probabilistic results.
WAP as other tools that do taint analysis (presented in Section 2.2.1.2) also does alias analysis for detecting vulnerabilities, although it goes further by also correcting the code. Furthermore, Pixy does only module-level analysis, whereas WAP does global analysis (i.e., the analysis is not limited to a module or file, but can involve several). Contrary to our work, the works presented in Section 2.3.1 that use data mining did not aim to detect bugs and identify their location, but to assess the quality of the software in terms of the prevalence of defects and vulnerabilities. WAP is quite different because it has to identify the location of vulnerabilities in the source code, so that it can correct them with fixes. Moreover, WAP does not use data mining to identify vulnerabilities, but to predict whether the vulnerabilities found by taint analysis are really vulnerabilities or false positives.
We propose to use the output of static analysis to remove vulnerabilities automatically. A few works use approximately the same idea of first doing static analysis then doing some kind of protection, but mostly for SQL injection and XSS, and without attempting to in- sert fixes to correct the source code in the same way than WAP. However, saferXSS (Shar & Tan, 2012a) also corrects the source code, but differently than WAP. After to find XSS vulnerabilities, it wraps the user inputs (entry points) with functions provided by OWASP’s ESAPI (OWASP,2014a). On contrary, WAP inserts fixes in the sensitive sinks with the aim of not to compromise the behavior of the application, since it deals with several classes of vulnerabilities. However, none of these works use data mining or machine learning.
The WAP tool corrects the code by inserting fixes, i.e., sanitization and validation func- tions. Testing is used to verify if the fixes actually remove the vulnerabilities and do not compromise the (correct) behavior of the applications. The tool was experimented with syn- thetic code with vulnerabilities inserted on purpose, and with a considerable number of open source PHP applications. It was also compared with two source code analysis tools: Pixy and PhpMinerII. This evaluation suggests that the tool can detect and correct the vulnerabilities of the classes it is programmed to handle. It was able to find 388 vulnerabilities in 1.4 million lines of code. Its accuracy and precision were approximately 5% better than PhpMinerII’s, and 45% better than Pixy’s.
4
Detecting Vulnerabilities using Weapons
Static analysis tools search for vulnerabilities in source code, helping programmers to fix the code. However, these tools are programmed to detect specific sets of flaws, often SQLI and XSS (Jovanovic et al.,2006;Nunes et al.,2015), occasionally a few other (case of WAP and (Dahse & Holz, 2014)), and are typically hard to extend to search for new classes of vulnerabilities. Furthermore, new technologies are becoming centric in web applications. An example are NoSQL databases, particularly convenient to store big data, like the MongoDB, the most used NoSQL database (DB-Engines,2015).
The chapter addresses the difficulty of extending these tools by proposing a modular and extensible version of the WAP tool (presented in Chapter3), equipping it with weapons (WAP extensions) to detect and correct new vulnerability classes. This involves restructur- ing the tool in: (1) modules for the vulnerability classes that it already detects; and, more importantly, (2) a new module to be configured by the user to detect and correct new vul- nerability classes without additional programming. This latter module takes as input data about the new vulnerability class: entry points (input sources), sensitive sinks (functions ex- ploited by the attack), and sanitization functions (functions that neutralize malicious input). Then it automatically generates a weapon composed of: a detector to search for vulnerabil- ities, symptoms to predict false positives, and a fix to correct vulnerable code. We used this scheme to enhance the new version of WAP with the ability to detect 7 new classes of vul- nerabilities: session fixation, header injection (or HTTP response splitting), email injection,
comment spamming injection, LDAP injection, XPath injection, and NoSQL injection. We also demonstrate that this modularity and extensibility can be used to create weapons that deal with non-native entry points, sanitization functions, and sensitive sinks. We show this point by creating a weapon to detect SQLI vulnerabilities in WordPress (WordPress,
2015), the most popular content management system (CMS) (Imperva,2015).
A second improvement to the tool was performed to make it more precise and accurate. We propose to increase the granularity of the analysis, adding more symptoms to the original set used in previous version of WAP and a new, larger, data set. A re-evaluation of machine learning classifiers was performed to select the new top 3 classifiers.
The version of WAP presented in this chapter is the first static analysis tool configurable to detect and correct new classes of vulnerabilities without programming. To the best of our knowledge, it is also the first static analysis tool that detects NoSQL injection and comment spamming injection (CI). The latter is currently the most exploited vulnerability in applica- tions based on WordPress (Imperva,2015).
The chapter is organized as follows. Section 4.1presents briefly the architecture of the WAP tool. Section4.2 explains the restructuring performed in the tool to make it modular and extensible. Section4.3presents the weapons we created to detect seven new classes of vulnerabilities and SQLI vulnerabilities in WordPress. Section4.4presents the experimental evaluation. The chapter ends with conclusions (Section4.5).
4.1
Architecture
This section presents briefly the architecture of the WAP tool (detailed version in Section
3.1). WAP detects input validation vulnerabilities in PHP web applications. This version of the tool handles eight vulnerability classes: SQLI, XSS (reflected and stored), remote file inclusion (RFI), local file inclusion (LFI), directory or path traversal (DT/PT), OS command injection (OSCI), source code disclosure (SCD), and PHP command injection (PHPCI).
WAP is developed in Java, and its implementation follows the architecture of Figure
3.2, and the approach presented in Section 3.1. It is composed of 3 modules represented summarily in Figure4.1and explained briefly as following:
1. Code analyzer: parses the source code, generates an abstract syntax tree (AST), does taint analysis, and generates trees describing candidate vulnerable data-flow paths