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