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.

Fig. 1: Security testing tools
Fig. 1: Security testing tools

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.

Explore Circuits and Projects Explore Videos and Tutorials

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).

Fig. 2: Security testing
Fig. 2: Security testing

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:

READ
"The Infotainment Industry Is Evolving Is Way Faster Than The Auto Industry"

http://Testexample.com/sale/itemsjsessionid=2P0OC2JSNDLPSKHCJUN2JV?destn =Delhi

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.

READ
Lightning has a very specific waveform, it is very important to know its characteristics to design circuit protection
Fig. 3: Wapiti test results
Fig. 3: Wapiti test results

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.

Netsparker Community Edition. Netsparker is a free web application security scanner. It helps the developers who want to scan their web applications instantly and find the vulnerabilities. Netsparker Community Edition scans for SQL injection, XSS, Boolean SQL injection, backup files and static tests. It scans all types of web applications without limiting itself to technology or platform they are built on. It supports Javascripts/AJAX, can show impact of vulnerabilities or remedy for that vulnerability.

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.

Fig. 4: OWASP ZAP test results
Fig. 4: OWASP ZAP test results

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.

Fig. 5: Netsparker Community Edition test results
Fig. 5: Netsparker Community Edition test results

Cookie set without HttpOnly flag (1). If a cookie has been set without the HttpOnly flag, it means the cookie can be accessed by JavaScript. If a malicious script can be run on this page then the cookie will be accessible and can be transmitted to another site. If this is a session cookie then session hijacking may be possible.

READ
NI Lowers Semiconductor Test Cost With RF Measurement Enhancements for the STS

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.

Cookie not marked as HTTPOnly. If a cookie, which is not marked HTTPOnly, sent by the application, is manipulated by the client side code (JavaScript, Java, etc), it could leave the site to XSS vulnerabilities. HTTPOnly cookies cannot be read by client-side script, so marking a cookie as HTTPOnly can provide additional layer of protection against XSS attacks.

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

LEAVE A REPLY