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.
No comments:
Post a Comment