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 (Jovanovicet al., 2006; Nuneset 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 Chapter 3), equipping it withweapons (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), andsanitization functions(functions that neutralize malicious input).
Then it automatically generates aweaponcomposed of: adetectorto search for vulnerabil- ities, symptomsto predict false positives, and a fixto 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.1 presents briefly the architecture of the WAP tool. Section 4.2 explains the restructuring performed in the tool to make it modular and extensible. Section 4.3 presents the weapons we created to detect seven new classes of vulnerabilities and SQLI vulnerabilities in WordPress. Section 4.4 presents the experimental evaluation. The chapter ends with conclusions (Section 4.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 Figure 4.1 and 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