Key challenges involved in penetration testing and vulnerability analysis of web applications

Penetration testing attempts to exploit any one of the vulnerabilities, weakness, technical flaws to gain unauthorized access. It is a method of evaluating the security of a computer system or network by simulating an attack by a malicious hacker. There are two types of penetration services:

Network Penetration Testing:

Network Penetration Testing attempts to break into a system’s network or servers. It involves use of tools, grab bags of tricks & exploits, network scanning, social engineering, port scanning etc.

Application Penetration Testing:

Application Penetration Testing does not involve network or servers. Its purpose is to find out the vulnerabilities in a software application using automated tools along with manual analysis. Usually a set of accounts is given to an auditor with varying level of privilege on the application, and is tasked to find  OWASP-type vulnerabilities in the application.

It helps in identifying vulnerabilities and risks in web applications. It helps in finding the vulnerabilities in URL manipulation, SQL injection, cross site scripting, back-end authentication, password in memory, session hijacking, buffer overflow, web server configuration, unauthorized logins, personal information modification, breach of customer trust etc 

Execution aspects of Web Application Pen Testing

It is a common myth that all security flaws can be detected by merely running automated tools.

Understanding the web application architecture and its business logic is the first and critical step in the security testing life cycle of web applications. Understanding of architecture, application functionality, interaction among various components of the application, data handled by the application, data flow, and the underlying technology is gained by browsing the application and detailed discussions with the system architects / developers of the application. 

Automated tools attempt to discover the structure of the application in one of the following two ways: In Spider mode the tool is given an initial starting URL of the application to be tested along with some information necessary to traverse through the application (e.g. credentials required for accessing the application). The second way is Manual recording mode where the security engineer browses through the application just as a typical user of the application would in the course of his normal interaction with the application. While this is going on, the tool captures and records information about pages visited as well as the data submitted. Automated tools cannot understand how data flows in the application, nor can they identify critical data in the application. Automated tools treat all portions of the application the same way because of this limitation. As a result, these tools cannot differentiate between critical and non-critical assets of the business application during the simulation of attacks. In order to overcome the deficiencies of these automated tools, human intervention and intelligent analysis is required. That is why assessing the security preparedness of the application is essential. Auditing an application for security involves interacting with the application designers and developers to discover the security mechanisms implemented within the application. For Example, the response of the software developers to an auditing question “Does any part of the application use dynamic SQL? If yes, how do you prevent SQL injection?” These type of questions help in determining whether SQL Injection is possible. The Analysis of  business processes and data is also a crucial part. This analysis is helpful in determining the application portions to be tested and vulnerabilities to be exploited. In an e-commerce application, critical business scenarios would be the login, shopping cart process etc

Understanding the attacker's view, characterizing the security of the system, and determining threats is not possible with automated tools. Automated tools cannot identify threats for a given application on their own. The Security Engineer needs to key in the threats into these tools. These tools are essentially helpful in storing the information about threats in a structured fashion. There are models like STRIDE and DREAD to categorize and rate the identified threats. These models are platform-and technology-neutral and can be used for threat modelling of most genres of applications.

Web applications have a number of well-known vulnerabilities like XSS, insecure session management. During the attack simulation the automated tool modifies the originally recorded requests and resubmits them using test data i.e. the injections database. Automated tools do these simulation attacks blindly without identifying the vulnerable fields or without understanding the underlying business logic. These attacks need to be supported by activities like threat modeling and test data creation to make them more effective.

For example, a securely designed application may respond to a simulated injection attack from a tool with a session logout. Since the tool has no way of detecting that it has been logged out, it continues to carry out its injections, unaware that the application is refusing to respond to these requests as these requests are from an expired session. As a result, the application is never really subjected to the number of attacks that the tool claims to have executed. Another example where these tools prove to be inadequate and the human touch is required is the detection of the stored XSS  vulnerability, which requires some understanding of how data flows through the application.

Testing business logic is not covered by automated tools. Most of the security testing efforts are concentrated on testing the well known vulnerabilities. There are various mechanisms and open source / commercial tools to test well known vulnerabilities. But hardly any efforts have been put into developing similar mechanisms and tools for business logic testing.

In an e-commerce application purchasing an item at $10 price or changing price of an item to $10 are potential threats. In a Leave Management application, being able to approve one's own leaves, or changing the leave balance are potential threats. Testing for such business scenarios using various techniques like escalation of privileges, session hijacking during the security testing efforts is essential.

Automated tools have a database of SQL constructs which they simply insert in every application request and the response is analyzed. These tools report the SQL injection vulnerability as being exploited incase there is no application error, unexpected input error etc.

This is an example of a false positive as we cannot solely rely on the vulnerabilities reported by tools. A sanity check and further analysis might indicate that the injection was not successful in the real sense i.e. no sensitive data was retrieved or deleted from database etc.

Another reason why analysis of results is important is the multiple occurrences of the same vulnerability.As discussed earlier, the automated tools simulate attacks blindly and they are not smart enough to analyze the results in real time. As a result these tools end up trying the same attack at all possible locations and report the findings. It is very important to analyze how many threats are actually exploited.

For example, while simulating XSS attack, these automated tools will try to inject scripts in all the fields. These tools will continue doing these injections even if they find that the application is vulnerable to XSS. Penetration testing involves exploiting security threats using both a manual and an automated approach. This uncovers various threats that can be exploited to harm the users and the application. The analysis phase now involves figuring out the actual loopholes which cause the threats. This would help to identify the vulnerabilities and the impact of those vulnerabilities on the entire application.

For Example, If we are able to gain administrator account access by manipulating some parameters, then we have exploited a threat in which a normal user can perform the functions of the administrator. Now the analyst knows that the underlying vulnerability is Insecure Id's and it's his job to find out the impact of this vulnerability on the entire application. This also helps in suggesting the appropriate mitigation strategies.

Suggesting mitigation strategies

Assessing web applications for security is not enough. Carrying out security testing and exploiting vulnerabilities is just half of the work; suggesting mitigation strategies for exploited vulnerabilities is also critical. Mitigation strategies help in preventing attackers from attacking the web application.

Some of the automated tools suggest mitigation strategies. These tools have repositories of

mitigation strategies for common vulnerabilities just like they have a repository of injections for attacks. Based on the attacks exploited these tools pick up a mitigation strategy associated with it and include it in the final report. The problem with these mitigation strategies is that these mitigation strategies are vanilla and popular and attackers often know how to bypass those mitigation strategies.

The Analysis phase consists of suggesting mitigation  strategies which are application specific on the basis of deep understanding of the application, underlying technology etc. This includes suggesting defense in depth kind of strategies i.e. strategies at different layers in the application which makes the software more secure. Hence, the mitigation strategies are not limited to the application but they also cover other components like web servers, application servers, database servers and so on.

Automated tools like Appscan and WebInspect scan the web application by crawling all user-visible pages and sending attack vectors for well-known vulnerabilities such as, cross-site scripting and SQL injection. Such penetration tests do not enumerate all possible vulnerabilities present in the application, for reasons discussed above, but are meant to gain unauthorized access. Vulnerability assessment, on the other hand, is performed by Test Analysts with the help of such scanning tools, and is expected to locate as many potential problems as possible.

With the web platform adding newer technologies all the time, like RIA (Web 2.0 rich Internet

applications), the automated tools end up playing a catch-up game while a Test Analyst is able to plug such gaping holes in the tool-based approach. For Ajax in fact, very few of the present-day tools are able to catch even all of the standard vulnerabilities.

Highly integrated applications are also difficult to scan using automated scanners. For example, webmail has always been tricky for the tools. The scanner in some cases has to learn how to send mail to itself and then analyze them, and in some cases it has to realize that the XSS filtering system can be used against itself.