Before digging into the details of web application security testing, let us first take a brief overview of application security testing. Security testing can be divided into security functional testing and security vulnerability testing.
Security functional testing ensures that the software security functions are implemented correctly and are consistent with security requirements based on their specifications. Software security requirements mainly include data confidentiality, integrity, availability, authentication, authorisation, access control, audit, privacy protection, security management, etc.
Security vulnerability testing is to discover security vulnerabilities as an attacker. Vulnerability refers to the flaws in system design, implementation, operation or management. It may be used to attack, resulting in a state of insecurity. Commonly found vulnerabilities in web applications include cross-site scripting, injection, security misconfiguration, session management and more.
Vulnerabilities of web applications may be accessed by using penetration testing. Source code analysis systems aim to help developers locate vulnerabilities in the underlying code of software programs and applications before they are put into production. Penetration testing is the practice of testing a computer system, network or web application to find vulnerabilities that an attacker could exploit.
Several researches are available which have compared some security testing tools from the viewpoint of their features, cost, services, functions and so on. In this article, we compare three tools—Wapiti, OWASP ZAP and Netsparker Community Edition in terms of architecture, software requirement and generated results for different parameters.
Common web application vulnerabilities
The common vulnerabilities of web applications are cross-site scripting, SQL injection, broken authentication, cross-site request forgery and session management. These vulnerabilities appear significantly in the Web Hacking Incident Database (WHID).
SQL injection. It is a code injection technique, used to attack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution. The best way of finding whether an application is vulnerable to attack is to ensure that all use of interpreters separates untrusted data from query. A rare and best way of attack is to inject malicious code into strings as metadata. Consequently, when the stored string is concatenated into a dynamic SQL query, the malicious code is executed. This can allow the tester to read and modify sensitive data contained in a database and take full control of the database server by exploiting vulnerabilities. Two attack scenarios are:
Scenario #1. The application uses untrusted data in the following vulnerable query:
String query = “SELECT * FROM customers WHERE custNAME=’” + request.getParameter(“name”) + “’”;
Scenario #2: Vulnerable query in Hibernate Query Language
Query HQLQuery = session.createQuery(“FROM customer WHERE custNAME=’“ + request.getParameter(“name”) + “’”);
In both scenarios, the attacker modifies the ‘name’ parameter value to send: ‘ or ‘1’=’1.
http://testexample.com/app/customerView?name=’ or ‘1’=’1
This changes the meaning of queries to return all the records from the customer table. More dangerous attacks could invoke stored procedures or modify data.
Broken authentication and session management. It includes all form of handling user authentication and management of active sessions. A site may be vulnerable if:
1. User authentication credentials aren’t protected when stored using hashing or encryption
2. Session IDs are exposed in the URL
3. Session IDs aren’t rotated after successful login and passwords
4. Session IDs and other credentials are sent over unencrypted connections
To impersonate a user, an attacker use leaks or flaws, such as exposed session IDs, accounts and passwords, in the authentication or session management. When attack is successful, an attacker may have the same privilege level of the system as that of a legal authorised user. An attack scenario is given below as an example:
Scenario #1: Ticket reservations application supports URL rewriting:
An authenticated user of the site mails the above link to his friends without knowing that he is also giving away his session ID. When his friends use this link, they will use his session and credit card information.
Cross site scripting. It is a web vulnerability in which malicious script is injected into the system in the form of input. Three major types of cross-site scripting exist. The first one is Reflected XSS, in which attacker injects browser-executable code within a single HTTP response. It is non-persistent. Second type is Stored XSS, which occurs when some malicious user-submitted data is stored in a database to be used in the creation of pages that will be served to other users later. Thus, visitors of the web page fall victim to this attack. The third, Local XSS, targets vulnerabilities that occur in the source code itself. It is a type of XSS vulnerability which does not originate from the local software of the user.
Fuzzing testing. Fuzzing is a type of negative testing that involves injecting unexpected, random data as an input to the application, to test the behaviour of application under random data. Fuzzing is used to find security loopholes in operating system, software, web application and coding errors.
Cross-site request forgery. Also known as a one-click attack or session riding, and abbreviated as CSRF or XSRF, it is a type of malicious exploit of a website whereby unauthorised commands are transmitted from a user that the website trusts.
Insecure direct object reference. It occurs when an application exposes an internal implementation object to the user. Some examples of internal implementation objects are database records, URLs or files. An attacker can modify the internal implementation object in an attempt to abuse the access controls on this object.
Comparison of security testing tools
In order to compare the representative testing tools, we consider the sample of web application Jammu and Kashmir Employment System. The system aims to immediately provide the facility for citizens to submit online form for the services identified by the state of Jammu & Kashmir. Subsequently, the citizen must be able to check the status of his/her application online. These submissions and status tracking can be done through the Common Service Centres (CSCs) or through the J&K State Portal directly.
Jammu and Kashmir Employment System will help the government of Jammu & Kashmir in creating an integrated information infrastructure that will expand, integrate and enhance the utility and reach of the services provided by the government by utilising the network of the CSCs. The state-portal is envisioned as an informative, interactive, integrated and trusted service delivery channel for the government to citizens (G2C) and government to business (G2B) services of the state and the government’s constituent departments. The SSDG acts as hub (standards-based messaging switch) for all the interactions and seamless interoperability across service seekers (the citizens and businesses) and various service providers (government departments) and even among government departments.
To test the representative tools, we configured each tool to run the test. The configuration included installation, setting up test parameters, test data, result analysis, etc.
We ran the test on the machines. Configuration for the machine was Intel core i3-3110M 2.40GHz processor with 2GB RAM, running Microsoft Windows. The tests were conducted two times a day to minimise the effect of the Internet connection on test results and to obtain accurate measurements.
Overview of tools
Wapiti. Wapiti is a web application vulnerability scanner that was created in 2006 by Nicolas Surribus. It does not scan the source code of the application but scans the web pages of the launched web application. Wapiti acts like a fuzzer and injects payloads to see if a script is vulnerable. Wapiti can detect lots of vulnerabilities, such as file-handling errors, database injection, cross-site scripting, LDAP injection and CRLF injection. Wapiti is easy to use, open source and the user does not need security knowledge. But it is not able to find all the vulnerabilities.
OWASP ZAP. OWASP ZAP is a penetration-testing tool which comes with plenty of features. Its main features is active scanning which is used to find certain kind of vulnerabilities, including XSS and others, except some logical vulnerabilities that can never be found by any automated security testing tool. Another interesting feature of ZAP is fuzzing. ZAP provides a list of fuzzers with the help of which we can fuzz any part of the application. This tool is open source, easy to use, well organised and up-to-date. High false positive factors and zero support for multiple scanning profiles are its main disadvantages.
Tools results and analysis
The web application was tested using the three tools OWASP ZAP, Wapiti and Netsparker Community Edition. The test results obtained using these tools were:
Testing results with Wapiti. Using Wapiti, the following four vulnerabilities were discovered in the Jammu & Kashmir application (the number in brackets refers to the number of occurrence of the vulnerability):
SQL injection (1): SQL injection is a technique that exploits a vulnerability occurring in the database of an application. It is a code injection that can allow the tester to read sensitive information from database and to modify it. SQL Injection occurs when input contains escaped characters, or user input is not strongly typed.
Blind SQL injection (1): Blind injection occurs when SQL injection is already present in the application but its result is not visible. Escaped characters should be handled properly to protect an application from SQL injection.
File handling (1): The attack is known as path traversal or directory traversal. Its aim is to access files which are stored outside the web root folder. The attacker tries to explore the directories stored in web server.
Command execution (1): This attack consists of executing system commands on the server. The attacker tries to inject this command in the request parameter.
Test results with OWASP ZAP
Using the active scanning feature of OWASP ZAP, 17 potential vulnerabilities were found, as mentioned below (the number following the vulnerability refers to the number of occurrence of the vulnerability):
Cross site request forgery(2). Also known as one-click attack or session riding, and abbreviated as CSRF or XSRF, it is a type of malicious exploit of a website whereby unauthorised commands are transmitted from a user that the website trusts.
X-Content Type Options header missing (7). The script and styleSheet elements will reject responses with incorrect MIME types if the server sends the response header ‘X-Content-Type-Options: nosniff’. This is a security feature which prevents MIME-type confusion based attacks.
X-Frame-Options header not set (7). In this case, X-Frame-Options header is not included in the HTTP response to protect against ClickJacking attacks. The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a < frame > or < iframe >. Sites can use this to avoid clickJacking attacks by ensuring that their content is not embedded into other sites.
Testing results with Netsparker
Using the scanner feature of Netsparker Community Edition, we discovered five potential vulnerabilities in the example site:
Password transmitted over HTTP. When a password is transmitted over HTTP, it is vulnerable in many ways. As the password is transmitted over HTTP, network analyser and packet sniffers can easily monitor the traffic and intercept password. HTTP is not considered to be a secure method of user authentication as stated by HTTP specification.
Internal server error. The server responded with an HTTP status 500. This is due to server-side error. Reasons may vary.
Version disclosure. This information can help an attacker gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of application.
Our study shows that Wapiti works like a fuzzer. It detects database injection, cross-site scripting, file handling, etc. The web scanning, fuzzing, crawling, report generation, etc features of OWASP ZAP are very useful for web application testing. Its Web Spider function automatically discovers the hidden links. It allows the tester to understand the structure of the web application. The active scanning feature of OWASP ZAP reports some main vulnerabilities, such as directory browsing, external redirects, session ID in URL rewrite and SQL injection. From all the features that OWASP ZAP offered, fuzzer is the best due to lots of fuzzing plugins that can be used. Also, the process of fuzzing is pretty optimised and fast. The thing that is weird about OWASP ZAP is that, when we scanned web application twice, we got different results. Netsparker community edition offers nice grouping of results and great detail per vulnerability.
Our comparison shows that different tools show different results for the same web application. Wapiti found SQL injection and Blind SQL injection in the application. Several studies show that Wapiti has highest percentage of SQL injection detections. Netsparker does not have Blind SQL Injection module, but is prone to less false positive factors as compared to other tools. OWASP ZAP found cross-site request forgery vulnerability in the web application. OWASP ZAP is prone to high false positive factors as compared to the other tools. It reported SQLi vulnerability as cross-site scripting. So we find that no tool is perfect but each can help to find some basic vulnerabilities.
The author is working as a project engineer at CDAC, Mumbai in automation testing. Her research interests are in software engineering, particularly in software testing and reliability, and software metrics