Sample WAPT Report V1.4

WEB APPLICATION
PENETRATION TESTING
REPORT
F OR
<<COMPANY NAME>>
F ROM
Assessment:
Penetration Testing Report
<<Company Name>>
CONTENTS
1 EXECUTIVE SUMMARY........................................................................... 6
1.1 SUMMARY.............................................................................................6
1.2 OBJECTIVE............................................................................................6
1.3 DURATION.............................................................................................6
1.4 APPROACH............................................................................................7
1.5 SCOPE OF WORK....................................................................................8
1.6 TYPE OF ASSESSMENT SELECTED BY <<COMPANY NAME>>...............................9
1.7 STANDARDS AND FRAMEWORK FOLLOWED....................................................11
1.8 SUMMARY OF FINDINGS..........................................................................12
1.9 TABULAR SUMMARY...............................................................................13
1.10............................................................................................... GRAPHICAL SUMMARY
13
1.11...................................................................................................... SEVERITY RATING
14
1.12.............................................................................................. EASE OF EXPLOITATION
15
2 TECHNICAL REPORT............................................................................ 16
2.1 WEB APPLICATION VULNERABILITIES...........................................................16
2.1.1 SQL INJECTION...................................................................................................... 16
2.1.2 UNRESTRICTED FILE UPLOAD.................................................................................... 22
2.1.3 APPLICATION ALLOWS REPLAY OF AUTHENTICATION TOKEN............................................28
2.1.4 INSUFFICIENT AUTHENTICATION.................................................................................31
2.1.5 INSUFFICIENT AUTHORIZATION.................................................................................. 32
2.1.6 DANGEROUS METHODS ENABLED............................................................................... 35
2.1.7 REPUDIATION ATTACK.............................................................................................. 37
2.1.8 WEAK PASSWORD RECOVERY MECHANISM..................................................................40
2.1.9 CROSS SITE SCRIPTING (XSS).................................................................................. 46
2.1.10 LDAP INJECTION.................................................................................................. 51
2.1.11 PADDING ORACLE ATTACK...................................................................................... 53
2.1.12 SESSION FIXATION................................................................................................ 56
2.1.13 SESSION HIJACKING............................................................................................... 59
2.1.14 INSECURE DIRECT OBJECT REFERENCES....................................................................62
2.1.15 CROSS SITE REQUEST FORGERY (CSRF)..................................................................66
2.1.16 CLICKJACKING VULNERABILITY..............................................................................70
2.1.17 DIRECTORY INDEXING............................................................................................ 73
2.1.18 PASSWORD TRANSMITTED OVER HTTP.....................................................................75
2.1.19 IMPROPER ERROR HANDLING..................................................................................77

2.1.20
2.1.21
2.1.22
2.1.23
2.1.24
2.1.25
2.1.26
2.1.27
2.1.28
2.1.29
2.1.30
2.1.31
2.1.32
2.1.33
2.1.34
<<Company Name>>
CAPTCHA NOT IMPLEMENTED................................................................................80

SENSITIVE INFORMATION DISCLOSURE.......................................................................82
PASSWORD VISIBLE WHILE RESETTING PASSWORD.......................................................84
SESSION TOKEN IN URL......................................................................................... 86
FRAME INJECTION.................................................................................................. 87
OPEN REDIRECTION.............................................................................................. 89
ABUSE OF FUNCTIONALITY..................................................................................... 90
INSECURE IMPLEMENTATION OF WSDL......................................................................92
WEAK PASSWORD POLICY...................................................................................... 95
CONTENT SPOOFING............................................................................................. 98
COOKIE NOT MARKED HTTPONLY.........................................................................100
VERSION DISCLOSURE IIS/ASP.NET.......................................................................102
BACK BUTTON BROWSING.................................................................................... 105
VIEWSTATE IS NOT ENCRYPTED.............................................................................. 108
FORM AUTO-COMPLETE ENABLED..........................................................................110
3 OWASP TOP TEN 2013....................................................................... 112

4 APPENDIX......................................................................................... 113
DOCUMENT DTAILS
DOCUMENT VERSION CONTROL
Date
Classification
Document Type
Submitted To
Designation
Address
Contact
Number
E-Mail
DOCUMENT SUBMISSION DETAILS

18 May 2016
Highly Confidential
DOCUMENT DISTRIBUTION LIST
<<Company Name>>
<<Company Name>>
NOTICE
This document contains information which is the intellectual property of Network
Intelligence (India) Pvt. Ltd. (also called Network Intelligence). This document is
received in confidence and its contents cannot be disclosed or copied without the
prior written consent of Network Intelligence.
Nothing in this document constitutes a guaranty, warranty, or license, expressed or
implied. Network Intelligence disclaims all liability for all such guaranties, warranties,
and licenses, including but not limited to: Fitness for a particular purpose;
merchantability; non infringement of intellectual property or other rights of any third
party or of Network Intelligence; indemnity; and all others. The reader is advised that
third parties can have intellectual property rights that can be relevant to this
document and the technologies discussed herein, and is advised to seek the advice of
competent legal counsel, without obligation of Network Intelligence.
Network Intelligence retains the right to make changes to this document at any time
without notice. Network Intelligence makes no warranty for the use of this document
and assumes no responsibility for any errors that can appear in the document nor
does it make a commitment to update the information contained herein.
COPYRIGHT
Copyright. Network Intelligence (India) Pvt. Ltd. All rights reserved.
TRADEMARKS
Other product and corporate names may be trademarks of other companies and are
used only for explanation and to the owners' benefit, without intent to infringe.
NII CONTACT DETAILS

Name
Title
Company
Address
Tel. No
Mobile No
E Mail
Manager Security Assessment
<<Company Name>>
1 EXECUTIVE SUMMARY
1.1 SUMMARY
<<Company Name>> had assigned Network Intelligence (I) Pvt. Ltd. the task of
carrying out assessment as included in the scope of work.
1.2 OBJECTIVE
The purpose of the test was to determine security vulnerabilities in their web
applications/network as listed in the scope. The tests were carried out assuming the
identity of an attacker or a user with malicious intent. Due care was taken not to
harm the servers as requested.
1.3 DURATION
This Penetration Test was performed from <<TimeLine>>. The detailed report about
each task and our findings are described below.
<<Company Name>>
1.4 APPROACH
1.
2.
3.
4.
5.
6.
7.
Performed broad scans to identify potential areas of exposure and services

Performed targeted scans and manual investigation to validate vulnerabilities
Understand the Application
Build business based test cases
Identified components to gain access
Identified and validated vulnerabilities
Ranked the vulnerabilities based on threat level, loss potential, and likelihood of
exploitation
8. Identified issues of immediate consequence and recommended solutions
9. Developed long-term recommendations to enhance security
10.Transferred knowledge through this report
Ensure
Ensure
continuous
continuous
improvement
by
improvement by
conducting
conducting
periodic
periodic
assessments
assessments
<<Company Name>>
Develop
Develop
thorough
thorough Plan
Plan
for
for testing
testing
Conduct
Conduct
Reconnaissance
Reconnaissance
Develop
Develop strategy
strategy
to
to enhance
enhance
security
posture
security posture
Perform
Perform
scanning
scanning
Document
findings &
gather proof-ofconcepts at all
Recommend
Recommend
solutions
solutions
Prioritize
Prioritize and
and
rank
rank
vulnerabilities
vulnerabilities
Build
Build Test
Test Cases
Cases
Try
Try and
and gain
gain
access
by
access by
exploiting
the
exploiting the
vulnerability
vulnerability
1.5 SCOPE
OF
Understand
Understand the
the
Application
Application
Conduct manual
manual
Conduct
testing
testing
Identify
Identify &
&
validate
validate
vulnerabilities
vulnerabilities
WORK
The scope of this penetration test was limited to the URLs mentioned below:
Sr.
Application
URL
No
1.6 TYPE
Sr
.
N
o.
OF ASSESSMENT SELECTED BY
Type
of Description
Penetration
Test approach
Black
Box
Assessment
Gray
Box
Assessment
Wireless
Assessment
Social
Engineering
Risk
Based
Penetration
<<Company Name>>
<<COMPANY NAME>>
In this approach we only know the URL of the

website. Enumeration of technologies, mapping
of the website, identification of fault injection
points,
determining
input
validation
vulnerabilities, or logical security vulnerabilities,
and the OWASP top 10 attacks are all part of this
exercise.
Often enough, a web application involves
authentication and authorization components. In
order to be able to test these, we request for a
dummy user account with the least level of
privileges within the application. Using this
account, we are able to log in and test for
various flaws in the authentication scheme, as
well as attempt to escalate our privileges and
bypass authorization restrictions.
Wireless hacking is done to gather all loopholes
possible
in
an
organizations
wireless
infrastructure. This is done with an intention to
gain unauthorized access and to try and exploit
as much as resources available. This activity
also involves doing war driving and collecting
the statistics like signal strength, encryption
type, SSID etc.
Controls can be put on systems and devices but
same does not hold true for the objects using
these systems (employees/temporaries). Social
Engineering is the method by which all the
hackers try and get the confidential and
business critical information by using various
techniques. This test focuses on exploiting and
finding out all the possible loopholes pertaining
to this domain so that your organization is
geared up to face social engineering attacks in
real life.
Traditional Penetration Testing approach only
focuses on the technical vulnerabilities. But
As
applicab
le
and
selected
by WCO
No
Yes
No
No
No

Testing
Source
Review
Code
Penetration
Testing
Vulnerability
Assessment
Business
Pentest
Logic
<<Company Name>>
Business Risk based approach not only focuses

on the technical vulnerabilities but also on the
risks presumed to the business of People
Interactive First, test cases pertaining to the
business threat model are developed and
Penetration test is carried out focusing majorly
on the cases. This method has many advantages
over
the
traditional
Penetration
Test
methodology.
And one of the biggest
advantages it has is that of being business
focused.
Source code review focuses on detecting the
vulnerabilities
early
in
the
Software
Development Life Cycle (SDLC) such as Dataflow
attacks, Cross Site Scripting (XSS), Injection
(SQL, File, XPATH, reflection, etc.), File
Inclusion/execution and Information Leakage.
This methodology will help People Interactive to
close the loopholes during the development and
testing phase.
Penetration
Test
focuses
on
identifying
vulnerabilities that are identified during the
vulnerability assessment phase and exploiting
the same to provide the impact of the same.
Vulnerability Assessment is the process of
identifying, quantifying, and prioritizing the
vulnerabilities of the components of IT
infrastructure.
Traditional Penetration Testing approach only
focuses on the technical vulnerabilities. But
Business Risk based approach not only focuses
on the technical vulnerabilities but also on the
risks presumed to the business of People
Interactive First, test cases pertaining to the
business threat model are developed and
Penetration test is carried out focusing majorly
on the cases. This method has many advantages
over
the
traditional
Penetration
Test
methodology.
And one of the biggest
advantages it has is that of being business
focused.
No
No
Yes
Yes
<<Company Name>>
(To know more kindly press control key and click on the type of Penetration Test
approach.)
The Penetration Test types selected by client are as checked in the table above. It is
highly recommended to go in for other types of Penetration Test types in future
projects for improving the overall security posture of your esteemed organization.
1.7 STANDARDS
1.
2.
3.
4.
AND
<<Company Name>>
FRAMEWORK FOLLOWED
Open Web Application Security Project Framework (OWASP)

Web Application Security Consortium (WASC)
The Open Source Security Testing Methodology Manual (OSSTMM)
National Institute of Standards and Technology (NIST)
<<Company Name>>
1.8 SUMMARY OF FINDINGS

Following table that summarizes the list of findings discovered during the project:
Sr.
Title
Severity Rating Ease
of
No.
Exploitation
1
SQL Injection
HIGH
EASY
2
Unrestricted File Upload
HIGH
EASY
3
Application
Allows
Replay
of
HIGH
MODERATE
Authentication Token
4
Insufficient Authentication
HIGH
MODERATE
5
Insufficient Authorization
HIGH
MODERATE
6
Dangerous Methods Enabled
HIGH
MODERATE
7
Repudiation Attack
HIGH
MODERATE
8
Weak
Password
Recovery
HIGH
MODERATE
Mechanism
9
Cross Site Scripting (XSS)
HIGH
MODERATE
10
LDAP Injection
HIGH
MODERATE
11
Padding Oracle Attack
HIGH
MODERATE
12
Session Fixation
HIGH
MODERATE
13
Session Hijacking
MEDIUM
MODERATE
14
Insecure Direct Object References
MEDIUM
MODERATE
15
Cross Site Request Forgery (CSRF)
MEDIUM
MODERATE
16
Clickjacking Vulnerability
MEDIUM
MODERATE
17
Directory Indexing
MEDIUM
MODERATE
18
Password Transmitted Over HTTP
MEDIUM
MODERATE
19
Improper Error Handling
MEDIUM
MODERATE
20
CAPTCHA Not Implemented
MEDIUM
DIFFICULT
21
Sensitive Information Disclosure
MEDIUM
DIFFICULT
22
Password Visible While the Resetting
LOW
EASY
Password
23
Session Token in URL
LOW
EASY
24
Frame Injection
LOW
EASY
25
Open Redirection
LOW
EASY
26
Abuse of Functionality
LOW
MODERATE
27
Insecure Implementation Of WSDL
LOW
MODERATE
28
Weak Password Policy
LOW
MODERATE
29
Content Spoofing
LOW
MODERATE
30
Cookie Not Marked as HTTPOnly
LOW
MODERATE
31
Version Disclosure IIS/ASP.NET
LOW
MODERATE
32
Back Button Browsing
LOW
DIFFICULT
33
ViewState Is Not Encrypted
LOW
DIFFICULT
34
Form Auto-Complete Enabled
LOW
DIFFICULT
<<Company Name>>
1.9 TABULAR SUMMARY

The following table summarizes the Systems Vulnerability Assessment:
Category
Description
Systems Vulnerability Assessment Summary
Number of Systems/IP Address
34
Number of Vulnerabilities found
19(Web Application)
High, Medium
Vulnerabilities
and
Low
Severity
13
13
V ULNERABILITY S UMMARY
1.10 GRAPHICAL SUMMARY
Overall Vulnerability Graph
13
13
8
High
Medium
Low
<<Company Name>>
1.11 SEVERITY RATING

This rating is reserved for system vulnerabilities that will result in serious impact to
the organization. Depending on the criticality of the system, risks of this magnitude
could represent a financial impact or damage customer and partner relationships.
HIGH
It is imperative that efforts be undertaken immediately to mitigate the vulnerabilities
in this category. All High severity levels are defined by the following examples:
(Potential) Trojan Horses
(Potential) Backdoor
File Read and Writes Exploit
Remote Command Execution
Database Access
Denial of Service
MEDIUM
Medium threats are defined by some of the following examples:
Denial of Service
Unencrypted protocol access
Disclosure of server details
Application errors
LOW
Low threats are defined by some of the following examples:
Services enabled with a past history of security flaws
Limited exploit of read
Directory browsing
Information Disclosure
Old software
General security recommendations
1.12 EASE
OF
<<Company Name>>
EXPLOITATION
There are no global parameters to assess the value of this parameter. There are
various factors that influence the value of the Ease of Exploitation.
EASY
Any vulnerability classified as easy would be straightforward to exploit. There could

be known the exploit code in the public domain that could be used to compromise the
target. The post exploitation impact would depend on the type of service offered on
the system.
MODERATE
Any vulnerability classified as moderate would need additional effort in terms of time,
resources (no of systems, processing speed etc.) Also, though there is straight
forward exploits available, they may or may not work due the architecture or the
design of the network. In this case even if there is a compromise it would be
reasonably hard to conclude. There could be other factors that would be needed to
aid the attack.
DIFFICULT
Any vulnerability classified as difficult could be purely informational. However though
they could only reveal some information about the target but would not have any
know issues in the public domain
<<Company Name>>
2 TECHNICAL REPORT
2.1 WEB APPLICATION VULNERABILITIES
2.1.1 SQL INJECTION
SEVERITY LEVEL
HIGH
E A S E O F E X P LO I TAT I O N
MODERATE
V U L N E R A B I L I T Y C L A SS I F I C AT I O N
A F F E C T E D S A M P L E URL
DESCRIPTION
SQL Injection is an attack technique used to exploit applications that construct SQL
statements from user-supplied input. When successful, the attacker is able to change
the logic of SQL statements executed against the database.
A N A LY S I S
During analysis it was found that affected parameter of web application was
vulnerable to SQL Injection.
As web application did not have proper checks for input validation to stop SQL
injection attacks such as whitelists, parameterized queries and user parameterized
stored procedures.
An attacker can supply crafted input to break out of the data context in which their
input appears and interfere with the structure of the surrounding query.
Below is the sample Affected Sample URL:
http://203.196.206.152/Global_Portal/openhouse/getpassword.aspx
Parameter Name: tktno
Extracted Information of Database
Backend Database: Oracle
Extracted Database Name
CTXSYS
MDSYS
OLAPSYS
PMSTM
PORTAL
SUGWEB
SYS
SYSTEM
<<Company Name>>
TMMLDEV
UGLOBAL
WKSYS
WMSYS
F IGURE 1: SQL E RROR ON P ARAMETER "L OGIN ID"
F IGURE 2: SQL I NJECTION E RROR G ENERATED B Y A PPLICATION
<<Company Name>>
F IGURE 3: E XTRACTING D ATABASE N AME USING SQL I NJECTION
Also it was found that Web service is also vulnerable to SQL injection.
We are able to execute select user from dual query below is the screenshots for the
same:
F IGURE 4: W EB S ERVICE SQL A NALYZER
<<Company Name>>
Also due to SQL Injection it was found that application stores password in clear text
format.
Extracted Information from Table CV_LOGIN form Portal
ID
LOGINID
L_NAME
L_STAT
DEPTLOG
SUB_DEPT
L_PASSWORLD
ACE FACT
ACE FACT
ACE FACT
ACE FACT
kvp29780
ENGINE FAC
ENGINE FAC
engine
ADMIN
ACE FACT
ADMIN-CVBU
ADMIN
AMS
AMS
AMS
AMS
APL
APL
APL
APL
I M PA C T
Various attacks can be delivered via SQL injection, including reading or modifying
critical application data, interfering with application logic, escalating privileges within
the database and executing operating system commands. We were also able to
bypass OTP password functionality using SQL injection.
An attacker can access Clear text password which is stored in database.
R EC O M M E N D AT I O N
Following are the recommendation to prevent SQL injection attack.
1. White list of acceptable values
if (Request.QueryString[0] != null)
{
string procuctname = Request.QueryString[0];
var regex = new Regex(@"^0*[A-Z][0-9]*$");
if (!regex.IsMatch(procuctname))
{
lblmessage.Text = "An invalid product name has been
specified."; return;
}
}
2. Use Parameterized Queries
if (Request.QueryString[0] != null)
{
string procuctname = Request.QueryString[0];
<<Company Name>>
SqlConnection con = new

SqlConnection(ConfigurationManager.ConnectionStrings["DB_ConnectionString"].Connect
ionString);
SqlCommand command = new SqlCommand("SELECT Product_Name,
Category_Name,Description FROM ProductMaster WHERE Product_Name =@Product_Name");
command.CommandType = System.Data.CommandType.Text;
command.Parameters.Add("@Product_Name", SqlDbType.VarChar,
40).Value = procuctname;
command.Connection = con;
con.Open();
GridView1.DataSource = command.ExecuteReader();
GridView1.DataBind();
con.Close();
}
<<Company Name>>
3. Use Parameterized Stored Procedures
if(Request.QueryString[0] != null)
{
SqlConnection con = new
SqlConnection(ConfigurationManager.ConnectionStrings["DB_ConnectionString1"].Connec
tionString);
string Product_Name = Request.QueryString[0];
SqlCommand command = new SqlCommand("sp_GetProducts", con);
command.CommandType = System.Data.CommandType.StoredProcedure;
command.Parameters.Add("@Product_Name", SqlDbType.VarChar).Value =
Product_Name;
command.Connection = con;
con.Open();
GridView1.DataSource = command.ExecuteReader();
GridView1.DataBind();
con.Close();
}
Also it is recommended to Use a cryptographically secure hash like SHA-2 for storing
password
http://zetetic.net/blog/2012/3/29/strong-password-hashing-for-aspnet.html.
REFERENCE
SQL Injection
http://en.wikipedia.org/wiki/SQL_injection
Stop SQL Injection Attacks before They Stop You
http://msdn.microsoft.com/msdnmag/issues/04/09/SQLInjection/
How To: Protect From Injection Attacks in ASP.NET
http://msdn.microsoft.com/en-us/library/ff647397.aspx
<<Company Name>>
2.1.2 UNRESTRICTED FILE UPLOAD

SEVERITY LEVEL
HIGH
MODERATE
DESCRIPTION
Uploaded files represent a significant risk to applications. The first step in many
attacks is to get some code to the system to be attacked. Then the attack only needs
to find a way to get the code executed. Using a file upload helps the attacker
accomplish the first step.
The consequences of unrestricted file upload can vary, including complete system
takeover, an overloaded file system, forwarding attacks to backend systems, and
simple defacement. It depends on what the application does with the uploaded file,
including where it is stored.
A N A LY S I S
The Affected Sample URL is vulnerable to unrestricted file upload.
1) As the web application doesn't validate content type for the uploaded files, we
could successfully upload a malicious file (web shell) on the server.
We were able to bypass the validation techniques used by the application by
supplying the filename string as filename.aspx;jpeg
F IGURE 5 U PLOADING A M ALICIOUS FILE S TEP 1
<<Company Name>>
F IGURE 6: UPLOADING A MALICIOUS FILE STEP 2
F IGURE 7: UPLOADING A MALICIOUS FILE STEP 3
2) After uploading the file, we were able to access the shell and browse through the
application
Source files. Also able to execute OS level command.
Extracted Information:
Command: net user
User accounts for \\TMPNERCC01
<<Company Name>>
------------------------------------------------------------------------------ACTUser
Administrator
ASPNET
FormsADUser
Guest
IUSR_TMPNERCC01
IWAM_TMPNERCC01
Karthikb.tcs
ORACLE
rashmi.tcs
reepal.tcs
rpttest
santosh1.tcs
SQLDebugger
SUPPORT_388945a0
tmersrvd
vinayk.tcs
The command completed successfully.
<<Company Name>>
Derived findings are issues which are discovered during the process of exploitation of
some other issues. These findings have been highlighted because the attacker can
leverage these issues in a compromised system to dig deeper into the network
leading to greater damage.
Below are the Derived findings:
Web.config was configured with Hardcoded Database Connection String
Data Source=M355 User ID=portal Password=portal123
Data Source=PAYWEB_NEW User ID=mbsuser Password=mbsuser123
F IGURE 8: C ONNECTION STRING IN WEB.CONFIG
Encryption key was found to be hardcoded in the source code.
I M PA C T
Using file upload vulnerability, an attacker can upload malicious code that can run
system level commands, browse system files, and can penetrate inside the network.
Also we are also able to download entire source code of the Application using
uploaded shell.
It is recommended to validate the following
Type of the files to be uploaded on the server side.
Content-type should be validated on the server side.
Size of the file
Do not send uploaded resumes directly via email to the internally employees. It
should be scanned for viruses.
File extension validation
string filepath = "";

protected void btnupload_Click(object sender, EventArgs e)
{
//Vulnerable Code
if (uploader.HasFile)
{
if (CheckFileExtension(uploader.PostedFile.FileName))
<<Company Name>>
{
filepath = Server.MapPath("../files/" +
uploader.PostedFile.FileName);
uploader.PostedFile.SaveAs(filepath);
btnviewfile.Visible = true;
Response.Write("File uploaded seccessfully.");
}
else
{
Response.Write("Invalid file.");
}
}
}
private bool CheckFileExtension(string filename)
{
string ext = Path.GetExtension(filename).ToLower();
if (ext == ".jpg" || ext == ".png" || ext == ".jpg")
{
return true;
}
else
{
return false;
}
}
Below is recommendation for the derived finding

It is recommended to encrypt connection string information stored in the
Web.config file.
Below is the reference link for the same
http://msdn.microsoft.com/en-us/library/dx0f3cf2(v=vs.85).aspx
REFERENCE
Uploading Files Using the File Field Control
http://msdn.microsoft.com/en-us/library/aa478971.aspx
Use of Hardcoded Credential
http://cwe.mitre.org/data/definitions/798.html

https://www.owasp.org/index.php/Unrestricted_File_Upload
<<Company Name>>
<<Company Name>>
2.1.3 APPLICATION ALLOWS REPLAY OF AUTHENTICATION TOKEN

SEVERITY LEVEL
HIGH
EASY
Insecure Implementation of Authentication Token-Reply Attack
DESCRIPTION
A replay attack occurs when an attacker copies a stream of messages between two
parties and replays the stream to one or more of the parties. Unless mitigated, the
computers subject to the attack process the stream as legitimate messages, resulting
in a range of bad consequences, such as redundant orders of an item.
A N A LY S I S
The Web based SSO implementation was found to be vulnerable to replay attack. The
token generation was found to be cryptographically weak which does not generate
random cipher text for a given user and role parameter. The user specific cipher text
can be generated from the below URL and then the same token can be used to login
on behalf of the user.
F IGURE 9: T OKEN G ENERATION

F IGURE 10: T OKEN FOR PERSONAL NO . 118317
<<Company Name>>
F IGURE 11: SUCCESSFUL LOGIN WITH THE TOKEN
I M PA C T
Any user can login into the system on behalf of the other user by knowing his
personal number and generating the cryptographic value for the vulnerable URL.
Below are the recommendations for Replay of authentication tokens:
Generate a cryptographic strength one-time random token which must be:

o Allowed to be used once
o Usable for the user it was created
o Transmitted via HTTPS
It is recommended to implement nonce token as this will prevent from Reply
attack.
Time stamping is another way of preventing a replay attack by signing the
request with a time-based token as a parameter and set an expiration time on
that token. The username and timestamp can be hashed and passed as a
parameter and then the same parameter should be checked for its validity.
If feasible, use Windows Identify Foundation for web based Single Sign-On.
REFERENCE
Reply Attack
https://www.owasp.org/index.php/Testing_for_WS_Replay_(OWASP-WS-007)
Windows Identity Foundation
http://msdn.microsoft.com/en-us/library/hh377151.aspx
http://blogs.msdn.com/b/usisvde/archive/2012/03/13/windows-azure-security-bestpractices-part-5-claims-based-identity-single-sign-on.aspx
Implementing Nonce
http://en.wikipedia.org/wiki/Cryptographic_nonce
<<Company Name>>
https://wiki.servicenow.com/index.php?title=Implementing_a_Nonce
<<Company Name>>
2.1.4 INSUFFICIENT AUTHENTICATION

SEVERITY LEVEL
HIGH
MODERATE
DESCRIPTION
Insufficient Authentication occurs when a web site permits an attacker to access
sensitive content or functionality without having to properly authenticate. Web-based
administration tools are a good example of web sites providing access to sensitive
functionality. Depending on the specific online resource, these web applications
should not be directly accessible without requiring the user to properly verify their
identity.
A N A LY S I S
I M PA C T
This weakness can lead to the exposure of resources or functionality to unintended
user, possibly providing attackers with sensitive information or even execute arbitrary
code.
Also, it is difficult to keep a track of the activities performed in application with user
making changes without authenticating himself.
Attacker can login with any user as application allows direct login which only needs
victim Personal no.
It is recommended to implement strong authentication and authorization mechanism
before accessing any sensitive information or Web Services. Use an authentication
framework or library such as Membership and Role Provide which ships with .Net 2.0,
OWASP ESAPI Authentication feature etc.
REFERENCE
http://projects.webappsec.org/w/page/13246939/Insufficient%20Authentication
Web Service Authentication
<<Company Name>>
http://msdn.microsoft.com/en-us/library/w67h0dw7(v=vs.71).aspx
<<Company Name>>
2.1.5 INSUFFICIENT AUTHORIZATION

SEVERITY LEVEL
HIGH
MODERATE
DESCRIPTION
Insufficient Authorization results when an application does not perform adequate
authorization checks to ensure that the user is performing a function or accessing
data in a manner consistent with the security policy. Authorization procedures should
enforce what a user, service or application is permitted to do. When a user is
authenticated to a web site, it does not necessarily mean that the user should have
full access to all content and functionality.
A N A LY S I S
I M PA C T
An attacker could read/modify/delete sensitive data, either by accessing the data
directly from a data store that is not properly restricted, or by accessing insufficientlyprotected, privileged functionality to read/modify/delete the data. This could lead to
confidentiality breach.
Normal User can perform Master and Admin activity.
Below are the steps performed to Approve Acquisition from normal user account:
Step 1: Created Requisition from Normal User
<<Company Name>>
F IGURE 12: C REATE OF R EQUISITIONS STEP 1
Step 2: Click below URL for Approval Click on Sent To PRO for Booking button
http://203.196.206.152/global_portal/Travel_Booking/
(x1ik1a55pkqg3145x0addbj5)/approval/sendtopro.aspx?travelno=700835
F IGURE 13 : A PPROVE OF R EQUISITIONS S TEP 2
F IGURE 14: T RAVEL R EQUEST ION S ENT TO PRO
<<Company Name>>
Step 3: Check the Status of Requisition
F IGURE 15: V ERIFY T HE S TATUS OF R EQUISITION
It is recommended to implement strong authorization in the application.
Divide the software into anonymous, normal, privileged, and administrative
areas. Reduce the attack surface by carefully mapping roles with data and
functionality. Use role-based access control (RBAC) to enforce the roles at the
appropriate boundaries.
Note that this approach may not protect against horizontal authorization, i.e., it
will not protect a user from attacking others with the same role.
Ensure that you perform access control checks related to your business logic.
These checks may be different than the access control checks that you apply to
more generic resources such as files, connections, processes, memory, and
database records.
For web applications, make sure that the access control mechanism is enforced
correctly at the server side on every page. Users should not be able to access
any unauthorized functionality or information by simply requesting direct
access to that page.
One way to do this is to ensure that all pages containing sensitive information
are not cached, and that all such pages restrict access to requests that are
accompanied by an active and authenticated session token associated with a
user who has the required permissions to access that page.
Use the access control capabilities of your operating system and server
environment and define your access control lists accordingly. Use a "default
deny" policy when defining these ACLs.
REFERENCE
http://projects.webappsec.org/Insufficient-Authorization
2.1.6 DANGEROUS
<<Company Name>>
METHODS ENABLED
SEVERITY LEVEL
HIGH
EASY
Server Misconfiguration
DESCRIPTION
Server Misconfiguration attacks exploit configuration weaknesses found in web
servers and application servers. Many servers come with unnecessary default and
sample files, including applications, configuration files, scripts, and web pages. They
may also have unnecessary services enabled, such as content management and
remote administration functionality. Debugging functions may be enabled or
administrative functions may be accessible to anonymous users.
Servers may include well-known default accounts and passwords. Failure to fully lock
down or harden the server may leave improperly set file and directory permissions.
Misconfigured SSL certificates and encryption settings, the use of default certificates,
and improper authentication implementation with external systems may compromise
the confidentiality of information.
Verbose and informative error messages may result in data leakage, and the
information revealed could be used to formulate the next level of attack. Incorrect
configurations in the server software may permit directory indexing and path
traversal attacks.
A N A LY S I S
During analysis it was found that below mentioned Dangerous HTTP methods were
enabled on the server.
PUT
Delete
Trace
COPY
MOVE
MKCOL
PROPFIND
SEARCH
<<Company Name>>
LOCK
UNLOCK
I M PA C T
As WebDAV was configured with write permission enable on the remote server
attacker can able to upload shell on the server. This can lead to compromise of entire
system as attacker can run OS level command on the target server. Also WebDAV also
has Modify and Delete method enable due to which attacker can modify and delete
any file from the remote application server.
Also, Attackers may abuse HTTP TRACE method to gain access to information in HTTP
headers such as cookies and authentication data.
It is recommended that restrict access for all dangerous method and if it is not being
used disable it.
For disabling dangerous method use IIS Lockdown
http://technet.microsoft.com/en-us/library/dd450372.aspx
REFERENCE
How to disable WebDAV for IIS 6
http://www.popmartian.com/tipsntricks/2009/05/20/howto-disable-webdav-in-iis-6/
White-Hat Cross-site Tracing Paper
http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
Multiple Web Servers Dangerous HTTP Method TRACE
http://osvdb.org/show/osvdb/877
2.1.7 REPUDIATION
<<Company Name>>
ATTACK
SEVERITY
HIGH
MODERATE
Repudiation attack
DESCRIPTION
A repudiation attack happens when an application or system does not adopt controls
to properly track and log users' actions, thus permitting malicious manipulation or
forging the identification of new actions. This attack can be used to change the
authoring information of actions executed by a malicious user in order to log wrong
data to log files. Its usage can be extended to general data manipulation in the name
of others, in a similar manner as spoofing mail messages. If this attack takes place,
the data stored on log files can be considered invalid or misleading.
A N A LY S I S
A repudiation attack happens when an application or system does not adapt controls
to properly track and log users' actions, thus permitting malicious manipulation or
forging the identification of new actions. This attack can be used to change the
authoring information of actions executed by a malicious user in order to log wrong
data to log files.
To achieve this we have to perform the steps mentioned below
Step 1: Logged in with VAPTUSER3 user.
Step 2: Capture the Add Joke request.
F IGURE 16: A DD J OKE R EQUEST
<<Company Name>>
Step 3: Change the HiddenUser_ID Value to 118316" which represent "Mr Sarita
Rajiv" User.
F IGURE 17: C HANGE H IDDEN U SER I D V ALUE
Step 4: Submit the request.
F IGURE 18: S UCCESSFULLY A DDED JOKE
Step 5: Successfully created request details by " Mr Sarita Rajiv " user.
F IGURE 19: J OKE H AS BEEN C REATED BY S ARITA R AJIV R EPUDIATION A TTACK S UCCESSFUL
I M PA C T
This issue targets the accountability of the transactions performed by the users of the
application. A user ABC can perform a transaction and make someone else
responsible for performing that transaction.
In this case an attacker can add a disturbing message to user A and make user B
responsible for sending the message.
<<Company Name>>
This attack can be used to change the record creator name in the application thereby
there is no accountability for the data related operations.
It was also possible for an attacker to add joke data, for which there was no
customer interaction required. For successful attack an attacker need to simply craft
such request and just need to change HiddenUser_ID value in that request.This
HiddenUser_ID represent the personal no which will point to user.Also this will break
the Accountability of the Web application.
The application should not be logging any user supplied input. If at all the business
requirement dictates to log a user supplied input then it is highly recommended that
you validate the user input. Also, for operations that required to be logged from the
audit trail point of view should be picked from the logged on session user.
REFERENCE
Repudiation Attack
https://www.owasp.org/index.php/Repudiation_Attack
<<Company Name>>
2.1.8 WEAK PASSWORD RECOVERY MECHANISM

SEVERITY
HIGH
MODERATE
Broken Authentication and Session Management
DESCRIPTION
Insufficient Password Recovery is when
obtain, change or recover another
authentication methods require users
passphrase. The user should be the only
be remembered precisely.
a web site permits an attacker to illegally

user's password. Conventional web site
to select and remember a password or
person that knows the password and it must
A N A LY S I S
Below are the issues found on password recovery mechanism:
1. Attacker can change victim password by just knowing his date of Birth which
can be retrieved from below mention URL.
Information Leakage of Date of Birth by changing p_no parameter.
http://203.196.206.152/Global_Portal/mytatamotors/Home/Forms/m_Emp_All_D
etails.aspx?p_no=655798&bday=1
http://203.196.206.152/Global_Portal/MBS/
(gj0fdbn5chmutgauzgscdyr2)/Login/Common/Forms/frm_sign_up.aspx?
action=register
Year can be guessed by an attacker as there is no User Lockout Policy been
implemented.
User Lockout Policy means that after 3-5 attempts the user should be locked
out from accessing the application and must contact the administrator for
resetting the password.
<<Company Name>>
We are able to get date of birth of employee by changing p_no value to

655798.below screenshot represent the same:
F IGURE 20: G ETTING D ATE O F BIRTH
Resetting password of 655798 by giving date of birth extracted in above screenshot

and brute forcing year below screenshot represent the same:
F IGURE 21: FORGOT PASSWORD FOR 655798
F IGURE 22: B RUTE FORCING Y EAR PARAMETER
<<Company Name>>
We are able to reset password by giving valid date of birth of employee below
screenshot represent the same
F IGURE 23: PASSWORD AND S ECURITY QUESTION ANSWER CHANGED FOR 655798
F IGURE 24: PASSWORD C HANGED S UCCESSFULLY
2. It was also found that application disclosed the Security Question answer and
Password in the response itself before submitting actual Security Question
answer.
Also it was observed that Security Question Answer for User is same as Login
Id.
For Example:
For Login Id: P118316
Security Question Answer: P118316
Below are the steps performed to achieve the same:

Visit Below URL
<<Company Name>>
http://203.196.206.152/Global_Portal/MBS/
(wtal5y45yrnmmn55odaavxbv)/Login/Common/Forms/frm_get_passw
ord.aspx
Enter value P118316 in Login ID press Submit button.
Now View Page Source you will find below information
<input name="hdnAnswer" id="hdnAnswer" type="hidden" value="P118316" />
<input name="hdnPassword" id="hdnPassword" type="hidden" value="Test@123" />
Security Question Answer: P118316
Password:
Test@123
F IGURE 25: S TEP 1 W EAK P ASSWORD M ECHANISM
F IGURE 26: S TEP 2 W EAK P ASSWORD M ECHANISM
Also, it was also found that password recovery mechanism implemented by

application was found to be weak as security question answer for most of the User is
found to same.
<<Company Name>>
<<Company Name>>
I M PA C T
An attacker could gain unauthorized access to the system by retrieving legitimate
user's authentication credentials. An attacker could deny service to legitimate system
users by launching a brute force attack on the password recovery mechanism using
personal no of legitimate users.
To prevent an attacker from forcing 'recovery' of the password, the application
should implement an additional step for recovery of password. Anyone attempting
to reset/recover the password should answer a 'security question' whose answer is
only known to the original user.
Do not use standard weak security questions and use several security questions.
Disable the password recovery functionality after a certain (small) number of
incorrect guesses.
Rather than emailing the original password in plain-text to the user's email
account, a one-time token URL can be generated, which the user can visit and 'set'
his/her password. This will help prevent shoulder-surfing attacks.
REFERENCE
Insufficient Password Recovery
http://projects.webappsec.org/Insufficient-Password-Recovery
OWASP Forgot Password Cheat Sheet
https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
<<Company Name>>
2.1.9 CROSS SITE SCRIPTING (XSS)

SEVERITY LEVEL
HIGH
MODERATE
Cross-Site Scripting
DESCRIPTION
XSS (Cross-Site Scripting) allows an attacker to execute a dynamic script (Javascript,
VbScript) in the context of the application. This allows several different attack
opportunities, mostly hijacking the current session of the user or changing the look of
the page by changing the HTML on the fly to steal the user's credentials. This
happens because the input entered by a user has been interpreted as
HTML/Javascript/VbScript by the browser.
XSS targets the users of the application instead of the server. Although this is a
limitation, since it allows attackers to hijack other users' session, an attacker might
attack an administrator to gain full control over the application.
A N A LY S I S
It was found that the application does not validate values of all parameters submitted
by the user.
In the above URLs, an attacker is able to send malicious input for the parameters
mentioned which is then rendered back on the webpage without any validation.
Attack Vector Used For XSS:
><script>alert(document.cookie)</script>
"/><b>NII</b>
The screenshots below show that the txtCategory parameter is edited to have a script
tag which prints out the cookie value in the alert box. This could also be used to log
the cookie value to an external site, which is controlled by attacker.
<<Company Name>>
F IGURE 27: CROSS SITE SCRIPTING ON TXT C ATEGORY
F IGURE 28: E XECUTION OF C ROSS S ITE S CRIPTING
Below screenshot show that parameter cat_id is affected with IE Specific XSS.
(Note: That this XSS attack works only through an IE browser)
<<Company Name>>
F IGURE 29: IE SPECIFIC XSS
I M PA C T
An attacker can use XSS to send a malicious script to an unsuspecting user. The end
users browser has no way to know that the script should not be trusted, and will
execute the script. Because it thinks the script came from a trusted source, the
malicious script can access any cookies, session tokens, or other sensitive
information retained by your browser and used with that site. These scripts can even
rewrite the content of the HTML page.
Following are the recommendation for cross site scripting attack.
1. White list parameter values i.e. accept only the known good.
if(Request.QueryString[0]!=null)
{
string productname = Request.QueryString[0];
var regex = new Regex(@"^[a-zA-Z]{1,20}$");
if (!regex.IsMatch(productname))
{
lblmessage.Text = "An invalid data has been submitted.";
}
}
2. Encode HTML output
string searchkeyword = Request.QueryString[0];

if(Request.QueryString[0]!=null)
{
<<Company Name>>
lblmessage.Text = "Search results for keyword : " +

HttpUtility.HtmlEncode(searchkeyword);
}
3. Encode URL output
if( Request.QueryString[0]!=null)
{
lblmsg.Text = "Search results for keyword : " + Encoder.UrlEncode(searchkeyword);
}
4. Enable ASP.NET request validation property

Page:
<%@ Page Language="C#" ValidateRequest="false"%>
Web.config:
<system.web>
<pages ValidateRequest="true" />
</system.web>
5. AntiXSS Library
if( Request.QueryString[0]!=null)
{
lblmsg.Text = "Search results for keyword : " + Encoder.HtmlEncode(searchkeyword);
}
<<Company Name>>
REFERENCE
HttpUtility.HtmlEncode Method
http://msdn.microsoft.com/en-us/library/system.web.httputility.htmlencode.aspx
Anti XSS Examples
Microsoft Anti-Cross Site Scripting Library
http://www.microsoft.com/en-us/download/default.aspx
2.1.10
<<Company Name>>
LDAP INJECTION
SEVERITY LEVEL
HIGH
MODERATE
LDAP Injection
DESCRIPTION
LDAP Injection is an attack technique used to exploit web sites that construct LDAP
statements from user-supplied input.
Lightweight Directory Access Protocol (LDAP) is an open-standard protocol for both
querying and manipulating X.500 directory services. The LDAP protocol runs over
Internet transport protocols, such as TCP. Web applications may use user-supplied
input to create custom LDAP statements for dynamic web page requests.
When a web application fails to properly sanitize user-supplied input, it is possible for
an attacker to alter the construction of an LDAP statement.
A N A LY S I S
I M PA C T
When an attacker is able to modify an LDAP statement, the process will run with the
same permissions as the component that executed the command. (e.g. Database
server, Web application server, Web server, etc.). This can cause serious security
problems where the permissions grant the rights to query, modify or remove anything
inside the LDAP tree. The same advanced exploitation techniques available in SQL
Injection can also be similarly applied in LDAP Injection.
The escape sequence for properly using user supplied input into LDAP differs
depending on if the user input is used to create the DN (Distinguished Name) or used
as part of the search filter. The listing below shows the character that needs to be
escape and the appropriate escape method for each case.
Used in DN - Requires \ escape
&
!
|
=
Used
<<Company Name>>
<
>
,
+
"
'
;
in Filter- Requires {\ASCII} escape
(
{\28}
)
{\29}
\
{\5c}
{\2a}
/
{\2f}
NUL
{\0}
REFERENCE
WASC
http://projects.webappsec.org/w/page/13246947/LDAP%20Injection
2.1.11
<<Company Name>>
PADDING ORACLE ATTACK
SEVERITY LEVEL
HIGH
MODERATE
A F F E C T E D URL
DESCRIPTION
traversal attacks.
A N A LY S I S
During analysis it was found that web application was vulnerable to Oracle padding
attack.
Oracle is a mechanism inside a cipher, capable of providing Valid or Invalid answer
for a given cipher-text. Therefore, Padding Oracle is a mechanism, capable to
answer, whether the padding of the provided cipher-text is valid or not.
In cryptography, the padding oracle attack is an attack on the CBC mode of
operation, where the "oracle" leaks data about whether the padding of an encrypted
message is correct or not. This can allow attackers to decrypt (and sometimes
encrypt) messages through the oracle using the oracle's key, without knowing the
encryption key.
We
are
able
to
find
Encrypted
value:
G2z2bgA1Kg_35BflQiApgAAAAAAAAAAAAAAAAAAAAA1
<<Company Name>>
F IGURE 30: O RACLE P ADDING E RROR
F IGURE 31: B RUTE FORCE E NCRYPTED V ALUE FOR O RACLE P ADDING ATTACK
I M PA C T
Using the vulnerability, the attacker may decrypt all the sensitive data, sent by
ASP.NET application to a client, i.e., cookies, ViewState, URL strings, hidden fields etc.
Then, the attacker may find your encryption passphrase, change the encrypted data
and send the modified content back to the server. For example, the attacker may
impersonate himself as a system administrator.
Microsoft has released a patch to fix the vulnerability. It is strongly recommended to
apply the below patch: http://technet.microsoft.com/en-us/security/bulletin/MS10-070
<<Company Name>>
It is recommended that a Patch Management process should be developed to ensure

regular application of security patches.
REFERENCE
OWASP - Insecure Configuration Management
http://www.owasp.org/index.php/Insecure_Configuration_Management
Padding oracle attack
http://en.wikipedia.org/wiki/Padding_oracle_attack
2.1.12
<<Company Name>>
SESSION FIXATION
SEVERITY LEVEL
HIGH
MODERATE
Session Fixation
ALL Application
DESCRIPTION
Session Fixation is an attack technique that forces a user's session ID to an explicit
value. Depending on the functionality of the target web site, a number of techniques
can be utilized to "fix" the session ID value. These techniques range from Cross-site
Scripting exploits to peppering the web site with previously made HTTP requests.
After a user's session ID has been fixed, the attacker will wait for that user to login.
Once the user does so, the attacker uses the predefined session ID value to assume
the same online identity.
A N A LY S I S
a) Enter the Login URL.
Cookie: ASP.NET_SessionId= islhvru154tcxn55neodtfj3
F IGURE 32: L OGIN B EFORE C OOKIE
b) Log into the application:

<<Company Name>>
F IGURE 33: L OGGED AFTER C OOKIE
c) Log out of the application: Cookie:ASP.NET_SessionId= islhvru154tcxn55neodtfj3
F IGURE 34: L OGOUT A FTER C OOKIE
d) Re-login without closing the browser :

F IGURE 35: R E L OGGED I N A PPLICATION
Since the Cookie values are same in all the above cases then it can lead to Session
Fixation Attack.
I M PA C T
After a successful attack, the attacker gains complete access to users session and
perform operations on the user's behalf whose session was hijacked.
<<Company Name>>
To counter session fixation attack, once should generate 3 session ids for each valid
user session i.e. Guest cookie once the user visits the page, login cookie once user
logs in to the application and again guest cookie once user logs out from the
application.
Below is the recommended approach:
1. Assign a session id when the user visits the website.
2. Assign a new session id when the user logs in to the website
3. Destroy the session id in generated in above step and allocate a new session id
after the user decides to log out.
4. The session ids should be strictly generated and validated on the server side.
Any session id from the client side should be validated on server side before
processing the request.
REFERENCE
OWASP: Testing for Exposed Session Variables
https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OWASP-SM004)
OWASP - Top 10 2010-A3-Broken Authentication and Session Management
http://www.owasp.org/index.php/Top_10_2010-A3
Session Fixation
http://projects.webappsec.org/Session-Fixation
7.
2.1.13
<<Company Name>>
SESSION HIJACKING
SEVERITY
MEDIUM
MODERATE
Application Misconfiguration
DESCRIPTION
The Session Hijacking attack consists of the exploitation of the web session control
mechanism, which is normally managed for a session token.
Because http communication uses many different TCP connections, the web server
needs a method to recognize every users connections. The most useful method
depends on a token that the Web Server sends to the client browser after a successful
client authentication. A session token is normally composed of a string of variable
with and it could be used in different ways, like in the URL, in the header of the http
requisition as a cookie, in other parts of the header of the http request, or yet in the
body of the http requisition.
A N A LY S I S
It was found that the application is vulnerable to Session Hijacking attack. The
following steps were performed to exploit the vulnerability:
Step 1: Open Firefox and log in as VAPTUSER3
Step 2: Grab the cookie from Firefox
F IGURE 36: SESSION H IJACKING S TEP 1- V ICTIM L OGGED IN APPLICATION
Step 3: Open Firefox Browser (Different System) and visit the login page and add the
cookie.
<<Company Name>>
F IGURE 37: A DDING V ICTIM C OOKIE O N A TTACKER S YSTEM
<<Company Name>>
Step 4: Now simply access the URL in Firefox and gain access to VAPTUSER3
account
F IGURE 38: S ESSION H IJACK S UCCESSFUL
I M PA C T
After successfully hijacking a session, the attacker gains complete access to user's
data, and is permitted to perform operations impersonating the user whose session
was hijacked.
To prevent misuse of a valid session, strict session management policies must be put
in place. The following practices can followed for better session management:
1. Use HTTPS and mark Cookies as Secure
2. Every new session should have a different session token (i.e. MyCookie
parameter value should change on each login event)
3. The session should have a time-out policy, so that the session logs-out
automatically after a pre-defined time of inactivity. The shorter the time the
better.
4. Do not allow concurrent sessions.
REFERENCE
Guarding Against Session Hijacking In ASP.NET
https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OWASP-SM004)
OWASP - Top 10 2010-A3-Broken Authentication and Session Management
http://www.dreamincode.net/forums/topic/61503-guarding-against-session-hijackingin-aspnet/
Foiling Session Hijacking Attempts
http://msdn.microsoft.com/en-us/magazine/cc300500.aspx
Prevent Concurrent Sessions
http://geekswithblogs.net/Frez/archive/2010/05/17/preventing-a-user-from-havingmultiple-concurrent-sessions.aspx
<<Company Name>>
2.1.14
<<Company Name>>
INSECURE DIRECT OBJECT REFERENCES
SEVERITY
HIGH
MODERATE
DESCRIPTION
Insufficient Authorization results when an application does not perform adequate
authorization checks to ensure that the user is performing a function or accessing
data in a manner consistent with the security policy. Authorization procedures should
enforce what a user, service or application is permitted to do. When a user is
authenticated to a web site, it does not necessarily mean that the user should have
full access to all content and functionality.
Applications frequently use the actual name or key of an object when generating web
pages. Applications dont always verify the user is authorized for the target object.
This results in an insecure direct object reference flaw. Testers can easily manipulate
parameter values to detect such flaws and code analysis quickly shows whether
authorization is properly verified.
A N A LY S I S
During analysis it was found that attacker can view the details of any employee by
just changing emp parameter to next value.
Also it was also possible for an attacker to View pass that has been created by other
User just by changing parameter visnum.
Below are the screenshot represents both the scenario:
<<Company Name>>
F IGURE 39: E NUMERATION OF U SER D ETAILS BY CHANGING EMP VALUE
F IGURE 40: G ETTING EMP INFORMATION OF NEXT EMPLOYEE NO
<<Company Name>>
F IGURE 41: A LLOWED O BJECT BY U SER D ILIP
F IGURE 42: A CCESSING P ASS WHICH DILIP WAS NOT AUTHORIZED FOR
I M PA C T
Such flaws can compromise all the data that can be referenced by the parameter.
Unless the name space is sparse, its easy for an attacker to access all available data
of that type.
Using this insecure direct object reference vulnerability an attacker can view other
user data which was not authorized by just changing parameter to next predictable
value.
<<Company Name>>
Below is the recommendation for Insecure Direct Object:
Check if the User is in session and has privileges to access the particular
resource. Use Role Based Access Controls using
Minimize user ability to predict object IDs/Names
Dont expose the actual ID/name of objects
Follow the link below for implementing the above recommendations
http://www.troyhunt.com/2010/09/owasp-top-10-for-net-developers-part-4.html
REFERENCE
Insecure Direct Object Reference
https://www.owasp.org/index.php/Top_10_2007-Insecure_Direct_Object_Reference
2.1.15
<<Company Name>>
CROSS SITE REQUEST FORGERY (CSRF)
SEVERITY
MEDIUM
MODERATE
Cross-Site Request Forgery
DESCRIPTION
A cross-site request forgery is an attack that involves forcing a victim to send an HTTP
request to a target destination without their knowledge or intent in order to perform
an action as the victim. The underlying cause is application functionality using
predictable URL/form actions in a repeatable way. The nature of the attack is that
CSRF exploits the trust that a web site has for a user
A N A LY S I S
There are certain operations in the application which are considered sensitive. These
operations make visible changes to the application and their interaction with other
components.
It was found that below mentioned operations can be performed by submitting a
single request to the server by a logged in user.
Below Screenshot represent the CSRF on Official Email Parameter.
<<Company Name>>
F IGURE 43: B EFORE CSRF E XECUTION
Below is the crafted HTML code which will fill victim official email address and
alternative
email
address
by
an
attacker
email
address
which
is
sunilyadav165@gmail.com.
F IGURE 44: C RAFTED HTML PAGE FOR CSRF POC
While victim is already logged in he will visit attacker crafted html page and click on
submit form.
F IGURE 45: W HILE L OGIN V ICTIM VISIT A TTACKER HTML PAGE
<<Company Name>>
F IGURE 46: A FTER C LICK S UBMIT IT WILL REDIRECT TO H OME P AGE
After clicking submit form if you notice victim official email address and alternative
email address has been changed to attacker email sunil.yadav165@gmai.com
F IGURE 47: A TTACKER E MAIL ID H AS BEEN ADDED TO VICTIM PROFILE
Crafted Sample CSRF URL for Published Document:

http://203.196.206.152/Global_Portal/mytatamotors/info_policy/Structure_mgmt/admi
n/pubdoc.aspx?
catpub=F&catarc=F&cat_id=12&doc_id=2&pub=F&sort=title&stype=Yes&page=0
Below screenshot show that if logged in victim click on above URL it will directly
published the document with cat id 12 and doc id 2.
<<Company Name>>
F IGURE 48: CSRF ON P UBLISH D OCUMENT
I M PA C T
As the name indicates, this is a request forgery attack in which the attacker
impersonates another legitimate user in targeting the victim website. Depending on
the functionality provided by the web application that is being targeted, the impact
can vary from annoyances to administrative control for the attacker.
The following mechanisms can be used to prevent CSRF attacks:
1. Implement the use of random CSRF tokens for challenge response. The server
should generate a random token for all pages containing sensitive operations.
When the user submits the request, the CSRF token should also be sent along.
The server should verify the original token value and only then process the
user request.
2. The application can implement a strong CAPTCHA just before any sensitive
request has to be submitted.
3. Depending on the criticality of the operation, the application could ask the user
to re-enter their account password.
4. It is also necessary to ensure that the application does not suffer from any
Cross-Site Scripting Vulnerabilities. XSS may be used to bypass the CSRF
protections implemented by the application.
Also, it is recommended use ViewStateUserKey property within the Viewstate. Please
refer below URL for the same.
https://www.owasp.org/index.php/CrossSite_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Viewstate_.28ASP.NET.29
REFERENCE
Cross-Site Request Forgery
http://projects.webappsec.org/Cross-Site-Request-Forgery
MSDN
http://msdn.microsoft.com/en-us/library/ms972969.aspx
2.1.16
<<Company Name>>
CLICKJACKING VULNERABILITY
SEVERITY LEVEL
MEDIUM
MODERATE
CLCIKJACKING Attack
DESCRIPTION
CLICKJACKING, also known as a "UI redress attack", is when an attacker uses multiple
transparent or opaque layers to trick a user into clicking on a button or link on
another page when they were intending to click on the top level page. Thus, the
attacker is "hijacking" clicks meant for their page and routing them to other another
page, most likely owned by another application, domain, or both.
Using a similar technique, keystrokes can also be hijacked. With a carefully crafted
combination of style sheets, iframes, and text boxes, a user can be led to believe
they are typing in the password to their email or bank account, but are instead typing
into an invisible frame controlled by the attacker.
A N A LY S I S
It was found that application was vulnerable to CLICKJACKING attack.
Below are the step performed to achieve this
Below screenshot shows Event Name asdas is checked as published.
F IGURE 49: CLICKJACKING S TEP 1
Attacker create html

invisible iframe.
file in which attacker load vulnerable URL in his iframe with
<<Company Name>>
Below screenshot represent the same.
F IGURE 50: C LICK JACKING IFRAME S TEP 2
While victim is already logged in Victim Visit Attacker domain and Clicks on Click Me
Button.
F IGURE 51: CLICKJACKING S TEP 3
After Clicking Click Me button if you notice event name with asdas has been
unpublished.
F IGURE 52: C LICK J ACKING S UCCESSFUL
<<Company Name>>
I M PA C T
This may potentially trick a genuine user into clicking on something different to what
the user perceives they are clicking on, thus potentially following or inviting some
existing connections or non-existing in their profile.
There are two main ways to prevent Clickjacking:
1. Sending the proper browser response headers that instruct the browser to not
allow framing from other domains
2. Employing defensive code in the UI to ensure that the current frame is the
most top level window.
For more information on Clickjacking defense
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
REFERENCE
http://projects.webappsec.org/Application-Misconfiguration
Clickjacking defense
https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet
2.1.17
<<Company Name>>
DIRECTORY INDEXING
SEVERITY LEVEL
MEDIUM
MODERATE
Insecure Indexing
DESCRIPTION
Insecure Indexing is a threat to the data confidentiality of the web-site. Indexing website contents via a process that has access to files which are not supposed to be
publicly accessible has the potential of leaking information about the existence of
such files, and about their content. In the process of indexing, such information is
collected and stored by the indexing process, which can later be retrieved (albeit not
trivially) by a determined attacker, typically through a series of queries to the search
engine. The attacker does not thwart the security model of the search engine. As
such, this attack is subtle and very hard to detect and to foil - its not easy to
distinguish the attackers queries from a legitimate users queries.
A N A LY S I S
It was found that the directory listing was enabled on the Affected Sample URLs of the
application.
Below screenshot show the directory listing was enable on above mentioned URL.
F IGURE 53: D IRECTORY I NDEXING
<<Company Name>>
I M PA C T
Directory Listings can aid an attacker by enabling them to quickly identify the
resources at a given path, and proceed directly to analyzing and attacking them.
There is not usually any good reason to provide directory listings, and disabling them
may place additional hurdles in the path of an attacker.
This can normally be achieved in two ways:
1. Configure web server to prevent directory listings for all paths beneath the web
root
2. Place into each directory a default file (such as index.htm) which the web
server will display instead of returning a directory listing.
REFERENCE
Insecure Indexing
http://projects.webappsec.org/Insecure-Indexing
Enable or Disable Directory Browsing in IIS 7
http://technet.microsoft.com/en-us/library/cc731109(v=ws.10).aspx
2.1.18
PASSWORD TRANSMITTED
OVER
<<Company Name>>
HTTP
SEVERITY
MEDIUM
MODERATE
Insufficient Transport Layer Protection
DESCRIPTION
Insufficient transport layer protection allows communication to be exposed to
untrusted third-parties, providing an attack vector to compromise a web application
and/or steal sensitive information. Websites typically use Secure Sockets Layer /
Transport Layer Security (SSL/TLS) to provide encryption at the transport layer.
However, unless the website is configured to use SSL/TLS and configured to use
SSL/TLS properly, the website may be vulnerable to traffic interception and
modification.
A N A LY S I S
It was found that the sensitive data (user credentials) are sent via the plain-text
protocol HTTP to the above URLs.
<<Company Name>>
F IGURE 54: P ASSWORD T RANSMITTED OVER HTTP
I M PA C T
Sensitive data like user credentials and credit card numbers, submitted over an
unencrypted connection are vulnerable to interception by an attacker who is suitably
positioned on the network. This includes any malicious party located on the user's
own network, within their ISP, within the ISP used by the application, and within the
application's hosting infrastructure. Even if switched networks are employed at some
of these locations, techniques exist to circumvent this defense and monitor the traffic
passing through switches.
Since user credentials are usually considered sensitive information,
recommended to be sent to the server over an encrypted connection.
Following the link below to implement SSL on IIS
http://support.microsoft.com/kb/299875
REFERENCE
Insufficient Transport Layer Protection
http://projects.webappsec.org/Insufficient-Transport-Layer-Protection
OWASP - Top 10 2010-A9-Insufficient Transport Layer Protection
http://www.owasp.org/index.php/Top_10_2010-A9Insufficient_Transport_Layer_Protection
it
is
2.1.19
<<Company Name>>
IMPROPER ERROR HANDLING
SEVERITY
MEDIUM
DIFFICULT
Information Leakage
DESCRIPTION
Information Leakage is an application weakness where an application reveals
sensitive data, such as technical details of the web application, environment, or userspecific data. Sensitive data may be used by an attacker to exploit the target web
application, its hosting network, or its users.
A N A LY S I S
It was observed that the application displays
application/database directly to the end-user.
It discloses the below information to the end User
Internal IP Address
Stack Trace
Database Information
Internal Path Disclosure
error
F IGURE 55: I MPROPER E RROR H ANDLING
messages
from
the
<<Company Name>>
I M PA C T
Error disclosures of applications help an attacker in getting specific information on the
applications being used in the network. This would enable the attacker to concentrate
more on the vulnerabilities of that application. Hence, version disclosures simplify the
task of an attacker.
ASP.NET provides a simple yet powerful way to deal with errors that occur in your web
applications. Define custom error pages such that they give our minimum amount of
information out in case of an error condition.,
1. Define custom error pages in web.config
<customErrors mode="RemoteOnly" defaultRedirect="/error.aspx">
<error statusCode="403" redirect="~/Forbidden.aspx" />
<error statusCode="404" redirect="~/404error.aspx" />
<error statusCode="500" redirect="~/scripterr.aspx" />
</customErrors>
2. Define Page_Error in .aspx page
protected void Page_Error(object sender, EventArgs e)

{
Exception objException = Server.GetLastError().GetBaseException();
ErrorLogDetails.WriteToEventLog(objException);
Server.ClearError();
}
3. Define Application_Error in Global.asax file
protected void Application_Error(object sender, EventArgs e)

{
Exception objException = Server.GetLastError().GetBaseException();
ErrorLogDetails.WriteToEventLog(objException);
}
<<Company Name>>
4. Using custom HTTP Module

http://www.dotnetspark.com/kb/2233-creating-http-module-for-exceptionhandling.aspx
REFERENCE
How to create custom error reporting pages in ASP.NET by using Visual C# .NET
ASP.NET Custom Error Pages
http://aspnetresources.com/articles/CustomErrorPages
2.1.20
CAPTCHA
<<Company Name>>
NOT IMPLEMENTED
SEVERITY LEVEL
MEDIUM
DIFFICULT
Insufficient Anti-automation
DESCRIPTION
Insufficient Anti-automation occurs when a web application permits an attacker to
automate a process that was originally designed to be performed only in a manual
fashion, i.e. by a human web user.
A N A LY S I S
It was observed that CAPTCHA is not implemented on the login page of the
application.
Using this vulnerability an attacker can automate the login process and perform a
brute force attack.
Below screenshot shows brute force on TravelBooking Application for User
VAPTUSER3
F IGURE 56 : CAPTCHA N OT I MPLEMENTED
I M PA C T
Due to insufficient anti-automation, an attacker can use automated tools to perform
malicious activities on the application which may lead into unauthorized access.
<<Company Name>>
It is recommended to have CAPTCHA implemented to ensure no automated scripts or

bots can run on the all the input forms on the Affected Sample URL.
Also it is recommended to use User Lockout Policy in which user must be lockout in
case of 3-5 failed attempt.
REFERENCE
Insufficient Anti-automation
http://projects.webappsec.org/Insufficient+Anti-automation
2.1.21
<<Company Name>>
SENSITIVE INFORMATION DISCLOSURE
SEVERITY LEVEL
MEDIUM
DIFFICULT
Information Leakage
DESCRIPTION
A N A LY S I S
During analysis it was found that application failed to protect the sensitive
information like log, Email Id, Internal IP & Internal path which is directly accessible
over the internet.
http://203.196.206.152/Global_Portal/mytatamotors/AssetDetails/frm_BMC.aspx
http://172.24.6.191/shared/Login_AR.jsp
http://203.196.206.152/Global_Portal/mytatamotors/Home/Forms/frm_CheckUser.aspx
?s_user=oVh6+RVe9RL9C2Kk0cYXxw==&app_code=A110
http://172.18.78.10/knome/sessions/generate
http://203.196.206.152/Global_Portal/info_policy/Structure_mgmt/user/page.aspx
The following email addresses were disclosed in the response:
asmita.ghate@tatamotors .com
dilip.trivedi@tatamotors .com
dnk@tatamotors.com
nikhat.siddiqui @tatamotors.com
nmg@tatamotors.com
pradeep@tatamotors.com
sachin.sharma@tatamotors .com
sanjay.dureja@tatamotors .com
shantanu.sapale @tatamotors.com
<<Company Name>>
F IGURE 57: INFORMATION DISCLOSURE LOG F ILE
I M PA C T
However, this can also have security implications if you leave it wide open to the
world. Anyone would be able to see who is visiting the site, the URLs, and sometimes
even find valuable information to compromised system.
The presence of email addresses within application responses does not necessarily
constitute security vulnerability. Email addresses may appear intentionally within
contact information, and many applications (such as web mail) include arbitrary thirdparty email addresses within their core content. However, email addresses of
developers and other individuals (whether appearing on-screen or hidden within page
source) may disclose information that is useful to an attacker; for example, they may
represent usernames that can be used at the application's login, and they may be
used in social engineering attacks against the organizations personnel. Unnecessary
or excessive disclosure of email addresses may also lead to an increase in the volume
of spam email received.
It is recommended to provide authentication before accessing such sensitive
information or restrict the access to only those host that need this information.
Also, You should review the email addresses being disclosed by the application, and
consider removing any that are unnecessary, or replacing personal addresses with
anonymous mailbox addresses (such as helpdesk@example.com).
REFERENCE
Information Leakage
https://www.owasp.org/index.php/Information_Leakage
2.1.22
PASSWORD
<<Company Name>>
VISIBLE WHILE RESETTING PASSWORD
SEVERITY LEVEL
LOW
EASY
Information Leakage
A F F E C T E D URL
DESCRIPTION
A N A LY S I S
During analysis it was found that reset user functionality
visible mode.
has password field in
F IGURE 58: P ASSWORD I N V ISIBLE MODE
I M PA C T
Attacker can use shoulder surfing techniques to get the agent password which is
visible directly while reset user password by the administrator.
It is recommended that the password field should not be visible directly
Below is the recommendation for not displaying password
<input type=password value= />

REFERENCE
Information Leakage
http://projects.webappsec.org/Information-Leakage
<<Company Name>>
2.1.23
SESSION
TOKEN IN
<<Company Name>>
URL
SEVERITY LEVEL
LOW
EASY
A N A LY S I S
During analysis it was found that web application contains a session token in GET
URL.
F IGURE 59: SESSION TOKEN IN URL
I M PA C T
Sensitive information within URLs may be logged in various locations, including the
user's browser, the web server, and any forward or reverse proxy servers between
the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed
around by users. They may be disclosed to third parties via the Referrer header when
any off-site links are followed. Placing session tokens into the URL increases the risk
that they will be captured by an attacker.
It is recommended to use cookie-based session rather that implementing Cookie-less
session.
The application should use an alternative mechanism for transmitting session tokens,
such as HTTP cookies or hidden fields in forms that are submitted using the POST
method.
Cookieless ASP.NET
The article below reviews the pros and cons of cookieless sessions and discusses why you
should avoid storing valuable information in the session state.
REFERENCE
Session Fixation
https://www.owasp.org/index.php/Session_fixation
2.1.24
<<Company Name>>
FRAME INJECTION
SEVERITY LEVEL
LOW
EASY
Frame Injection
DESCRIPTION
Frame injection occurs when a frame on a vulnerable web page displays another web
page via a user-controllable input.
A N A LY S I S
During analysis it was found that application was vulnerable to frame injection
vulnerability.
Below is the screenshot for the same:
F IGURE 60: F RAME I NJECTION
<<Company Name>>
I M PA C T
An attacker might use this vulnerability to redirect users to other malicious websites
that are used for phishing and similar attacks.
Below is the recommendation for Frame Injection:
Where possible do not use users' input for URLs.
If you definitely need dynamic URLs, make a list of valid accepted URLs and do
not accept other URLs.
Ensure that you only accept URLs which are located on accepted domains.
REFERENCE
Frame Injection
https://www.mavitunasecurity.com/frame-injection/
2.1.25
<<Company Name>>
OPEN REDIRECTION
SEVERITY LEVEL
LOW
EASY
Open Redirection
DESCRIPTION
Open redirection occurs when a vulnerable web page is being redirected to another
web page via a user-controllable input.
A N A LY S I S
During analysis it was found that application was vulnerable to Open Redirection
Issue.
I M PA C T
An attacker can use this vulnerability to redirect users to other malicious websites,
which can be used for phishing and similar attacks.
Below is the recommendation for the same:
Where possible, do not use users' input for URLs.
If you definitely need dynamic URLs, make a list of valid, accepted URLs and do
not accept other URLs.
Ensure that you only accept URLs which are located on accepted domains.
REFERENCE
Open Redirection
http://www.owasp.org/index.php/Open_redirect
2.1.26
ABUSE OF
<<Company Name>>
FUNCTIONALITY
SEVERITY
LOW
MODERATE
DESCRIPTION
Abuse of Functionality is an attack technique that uses a web site's own features and
functionality to attack itself or others. Abuse of Functionality can be described as the
abuse of an application's intended functionality to perform an undesirable outcome.
These attacks have varied results such as consuming resources, circumventing
access controls, or leaking information. The potential and level of abuse will vary from
web site to web site and application to application. Abuse of functionality attacks are
often a combination of other attack types and/or utilize other attack vectors.
A N A LY S I S
Web Applications that send mail must be careful to not allow the user complete
control over message headers and content. If an attacker can control the From, To,
Subject, and Body of a message and there are no anti-automation controls in place
email functions can be turned into spam-relay vehicles.
<<Company Name>>
F IGURE 61: A BUSE OF F UNCTIONALITY S PAM A BUSE
I M PA C T
Web Applications that send mail must be careful to not allow the user complete
control over message headers and content. If an attacker can control the From, To,
Subject, and Body of a message and there are no anti-automation controls in place
email functions can be turned into spam-relay vehicles.
Below are the recommendations for the same:
It is recommended to use CAPTHA.
REFERENCE
http://projects.webappsec.org/w/page/13246913/Abuse%20of%20Functionality
2.1.27
INSECURE IMPLEMENTATION
OF
<<Company Name>>
WSDL
SEVERITY
LOW
MODERATE
DESCRIPTION
Application Misconfiguration attacks exploit configuration weaknesses found in web
applications. Many applications come with unnecessary and unsafe features, such as
debug and QA features, enabled by default. These features may provide a means for
a hacker to bypass authentication methods and gain access to sensitive information,
perhaps with elevated privileges.
A N A LY S I S
It was observed that the web-services which are consumed by the application are
accessible to an unauthenticated user.
These web-services are called by the web applications in the background to perform
all transactions.
F IGURE 62: A UTOMATIC G ENERATION O F WSDL
<<Company Name>>
F IGURE 63: POST I MPLEMENTATION OF WSDL
I M PA C T
Attacker can gain information of web-services listed and running on web server. Such
unauthenticated web service may reveal lot of information about the operations
which can be performed using such web service.
An attacker can also perform the operations listed in the web-services without having
to use the application.
It is recommended to make below changes in the web.config to disable automatic
generation of WSDL and POST method.
<webServices>
<protocols>
<remove name="HttpPost"/>
<remove name="Documentation"/>
</protocols>
</webServices>
REFERENCE
Control WSDL File Generation for ASP.NET Web Services
http://msdn.microsoft.com/en-us/library/ms242494
Configuring WSDL File Generation for ASP.NET Web Services
http://msdn.microsoft.com/en-us/library/ms242476
2.1.28
<<Company Name>>
WEAK PASSWORD POLICY
SEVERITY
LOW
MODERATE
DESCRIPTION
A brute force attack is a method to determine an unknown value by using an
automated process to try a large number of possible values. The attack takes
advantage of the fact that the entropy of the values is smaller than perceived.
A N A LY S I S
During analysis it was found that admin can set agent password to 1 character as it
has been validate on client side. Also, it was observed that no lockout policy has been
set for all the application.
F IGURE 64: W EAK P ASSWORD P OLICY STEP 1
<<Company Name>>
F IGURE 65: W EAK P ASSWORD P OLICY S TEP 2
F IGURE 66: W EAK P ASSWORD P OLICY S TEP 3
I M PA C T
Accounts with weak passwords are easily brute-force able.
An attacker can gain un-authorized access to application by guessing the passwords
for such accounts.
It is recommended that the application enforce complexity for the passwords that
users are permitted to keep.
Below are some best practices:
1. The minimum length of password should be 8 characters
2. Password should contain a combination of alpha-numeric characters and
special characters.
3. Users should change their password at least once in 30 days.
4. The change password should be different from the previous passwords.
5. Easy to guess passwords should not be used.
6. Users should not use dictionary words.
7. All the above has to be done on the server side.

REFERENCE
Brute Force
http://projects.webappsec.org/Brute-Force
Blocking Brute Force Attacks
www.owasp.org/index.php/Blocking_Brute_Force_Attacks
<<Company Name>>
2.1.29
<<Company Name>>
CONTENT SPOOFING
SEVERITY LEVEL
LOW
MODERATE
Open Redirection
DESCRIPTION
Open redirection occurs when a vulnerable web page is being redirected to another
web page via a user-controllable input.
A N A LY S I S
It was found that Affected Sample URLs are vulnerable to content spoofing. Whatever
message or string value is in entered in the get parameter, it is been rendered back
as is.
Though it does not allow HTML tags, but any other string value is allowed by
application
F IGURE 67: CONTENT SPOOFING ATTACK
I M PA C T
Content Spoofing is an attack technique that allows an attacker to inject a malicious
payload that is later misrepresented as legitimate content of a web application.
It is recommended to create global variables for such purpose and store all your
possible messages in them and use these variables rather than user input message.
REFERENCE
Content Spoofing

https://www.owasp.org/index.php/Content_Spoofing
<<Company Name>>
2.1.30
<<Company Name>>
COOKIE NOT MARKED HTTPONLY
SEVERITY
LOW
MODERATE
DESCRIPTION
A N A LY S I S
It was observed that the cookies being sent and received by the server, for storing
the sever state, are not being Marked as HTTPonly.
F IGURE 68: C OOKIE N OT M ARKED A S HTTPO NLY
I M PA C T
As the HTTPOnly attribute is not set, the browsers (which support the attribute) will
allow any client-side script to access the value of the cookie. An attacker can thus
gain access to a legitimate user's session IDs.
<<Company Name>>
Below are the different ways to set Httponly flag in asp.net.

1. Web.config
<system.web>
<httpCookies httpOnlyCookies="true"/>
</system.web>
2. Application_EndRequest event in Global.asax
protected void Application_EndRequest(Object sender, EventArgs e)

{
string authCookie = FormsAuthentication.FormsCookieName;
foreach (string sCookie in Response.Cookies)
{
if (sCookie.Equals(authCookie))
{
Response.Cookies[sCookie].Path += ";HttpOnly";
}
}
}
REFERENCE
HTTPOnly - OWASP
http://www.owasp.org/index.php/HttpOnly
HttpCookie.HttpOnly Property in ASP.NET
http://msdn.microsoft.com/en-us/library/system.web.httpcookie.httponly.aspx
How to Secure ASP .NET Cookies
http://www.dotnetnoob.com/2010/11/how-to-secure-aspnet-cookies.html
2.1.31
<<Company Name>>
VERSION DISCLOSURE IIS/ASP.NET
SEVERITY
LOW
MODERATE
DESCRIPTION
traversal attacks.
A N A LY S I S
During analysis following Version Issue was found on above mentioned URL/IP.
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
<<Company Name>>
F IGURE 69: V ERSION D ISCLOSURE
I M PA C T
Information disclosure in banner grab reveals sensitive data, such as technical details
of the web server, environment, or user-specific data. Sensitive data may be used by
an attacker to exploit the target web application, its hosting network, or its users.
This helps an attacker to launch target specific attacks.
To Fix IIS version information
1) Download URLScan Security Tool from the link mentioned in the reference
below. Install it thereafter.
2) Stop the IISAdmin service.
3) Navigate
to
Urlscan
folder
(default
location:
%systemroot
%\System32\Inetsrv\Urlscan)
4) Open the Urlscan.ini file in Notepad or WordPad.
5) Locate
&
modify
the
entry
RemoveServerHeader=0
to
RemoveServerHeader=1.
6) Save this file.
7) Start the IISAdmin service
To fix
1)
2)
3)
4)
the ASP.NET information disclosure

Open IIS Manager from Start > All Programs > Administrative Tools
Right click the current (in-use) Website and select Properties
Select the "HTTP Headers" tab (see figure below)
Under Custom HTTP header section choose "X-Powered-By: ASP.NET" and press
delete
5) Press Ok to exit the Web Site Properties
6) Restart the IISAdmin service
REFERENCE
<<Company Name>>
URLScan
http://www.iis.net/download/urlscan
Mask IIS Version Information from Network Trace and Telnet
Hiding Banner for IIS 7.0
http://force5blog.com/technology/hide-iis7-response-headers/
2.1.32
<<Company Name>>
BACK BUTTON BROWSING
SEVERITY LEVEL
LOW
MODERATE
DESCRIPTION
A N A LY S I S
It was observed that we can press the 'back-space' key (or back arrow) and are taken
to the previously in-use page.
To perform Back Button Browsing follows given procedure:
1. Login into the application.
F IGURE 70: B ACK B UTTON B ROWSING S TEP 1
2. Logout form the application.
<<Company Name>>
F IGURE 71: B ACK B UTTON B ROWSING S TEP 2
3. Now, press the back-button. User can see perform activity even after logout.
F IGURE 72: BACK BUTTON BROWSING STEP 3
I M PA C T
Any user related data displayed by the application is by-nature, sensitive. Thus when
an attacker hits the back-space and is shown the last-visited page by the user, it
violates the confidentiality of the user's account.
In the Page_Load event for the logout.aspx page, enter the following code:
Response.Cache.SetExpires(DateTime.UtcNow.AddMinutes(-1));
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
REFERENCE
Insufficient Session Expiration
http://projects.webappsec.org/Insufficient-Session-Expiration
2.1.33
VIEWSTATE
IS NOT
<<Company Name>>
ENCRYPTED
SEVERITY LEVEL
LOW
DIFFICULT
DESCRIPTION
A N A LY S I S
It was found that the__VIEWSTATE parameter was not encrypted. Viewstate is clientside session management technique which is used to page-level data. By default, it is
Base64 encoded.
To reduce the chance of someone intercepting the information stored in the
ViewState, it is good design to encrypt the ViewState.
F IGURE 73: V IEW S TATE N OT E NCRYPTED
I M PA C T
<<Company Name>>
An attacker can study the application's state management logic for possible
vulnerabilities and if your application stores application-critical information in the
ViewState; it will also be revealed. This can also be used to perform Cross site
scripting attack.
ASP.NET provides encryption for ViewState parameters.
For page based protection, place the following directive at the top of affected page.
<%@Page ViewStateEncryptionMode="Always" %>
You can also set this option for the whole application by using web.config files. Apply
the following configuration for your application's web.config file.
<System.Web>
<pages viewStateEncryptionMode="Always">
</System.Web>
REFERENCE
ASP.NET View State Security
http://weblogs.asp.net/varad/archive/2005/02/04/367056.aspx
2.1.34
<<Company Name>>
FORM AUTO-COMPLETE ENABLED
SEVERITY LEVEL
LOW
DIFFICULT
DESCRIPTION
A N A LY S I S
Auto-complete stored completed form fields like usernames and passwords locally in
the browser, so that these fields are filled automatically when the user visits the site
again.
Below screenshot represent that browser stores the value for Username parameter
in his browser cache.
F IGURE 74: A UTO C OMPLETE E NABLE
I M PA C T
Data entered in these fields will be cached by the browser. An attacker who can
access the victim's browser could steal this information. This is especially important if
<<Company Name>>
the application is commonly used in shared computers such as local area networks,
cyber cafes or airport terminals etc.
It is recommended to add the attribute autocomplete="off" to the form tag or to
individual "input" fields that you don't want the browser to cache.
REFERENCE
<<Company Name>>
3 OWASP TOP TEN 2013

Name
A1-Injection
A2 Broken
Authentication and
Session
Management
A3 Cross-Site
Scripting (XSS)
A4 Insecure Direct
Object References
A5 Security
Misconfiguration
A6 Sensitive Data
Exposure
A7 Missing
Function Level
Access Control
Description
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 attackers hostile data can trick the
interpreter into executing unintended commands or
accessing data without proper authorization.
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.
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
victims browser which can hijack user sessions, deface web
sites, or redirect the user to malicious sites.
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.
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.
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.
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.

A8 - Cross-Site
Request Forgery
(CSRF)
A9 - Using
Components with
Known
Vulnerabilities
A10 Unvalidated
Redirects and
Forwards
<<Company Name>>
A CSRF attack forces a logged-on victims browser to send a

forged HTTP request, including the victims session cookie
and any other automatically included authentication
information, to a vulnerable web application. This allows the
attacker to force the victims browser to generate requests
the vulnerable application thinks are legitimate requests
from the victim.
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.
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.
4 APPENDIX
Type of
Penetration
Testing
Approach
Black Box
Approach
Grey Box
Approach
War Dialing
Wireless Hacking
Description
Here, we only know the URL of the website. Enumeration of

technologies, mapping of the website, identification of fault
injection points, determining input validation vulnerabilities, or
logical security vulnerabilities, and the OWASP top 10 attacks are
all part of this exercise.
Often enough, a web application involves authentication and
authorization components. In order to be able to test these, we
request for a dummy user account with the least level of
privileges within the application. Using this account, we are able
to log in and test for various flaws in the authentication scheme,
as well as attempt to escalate our privileges and bypass
authorization restrictions.
Isa Penetration Test technique in which a list of telephone
numbers are called to search for computers, systems and fax
machines. The purpose is to gain as much as business critical
data as possible with the help of this technique.
Wireless hacking is done to gather all loopholes possible in an
organizations wireless infrastructure. This is done with an
Social
Engineering
War Driving
Business Risk
Based Approach
Source Code
Review
Internal
Penetration
Testing
Vulnerability
Assessment
Stress Testing
<<Company Name>>
intention to gain unauthorized access and to try and exploit as

much as resources available.
Controls can be put on systems and devices but same does not
hold
true
for
the
objects
using
these
systems
(employees/temporaries). Social Engineering is the method by
which all the hackers try and get the confidential and business
critical information by using various techniques. This test focuses
on exploiting and finding out all the possible loopholes pertaining
to this domain so that your organization is geared up to face
social engineering attacks in real life.
War driving can be carried to test the range and strength of your
organizations wireless networks signal. This will help to gauge
the extent of the threat exposure area for your organization.
Traditional Penetration Testing approach only focuses on the
technical vulnerabilities. But Business Risk based approach not
only focuses on the technical vulnerabilities but also on the risks
presumed to the business of <<Company Name>> First, test
cases pertaining to the business threat model are developed and
Penetration test is carried out focusing majorly on the cases. This
method has many advantages over the traditional Penetration
Test methodology. And one of the biggest advantages it has is
that of being business focused.
Source code review focuses on detecting the vulnerabilities early
in the Software Development Life Cycle (SDLC) such as Dataflow
attacks, Cross Site Scripting (XSS), Injection (SQL, File, XPATH,
reflection, etc.), File Inclusion/execution and Information
Leakage. This methodology will help <<Company Name>> to
close the loopholes during the development and testing phase.
Many organizations secure their organization from outside
threats but leave their internal network security comparatively
weak. And it has been proved over and over again that the
organizations security was compromised from within the
network. Internal Penetration Test focuses on identifying these
loopholes and recommending solutions to make the internal
network secure to thwart internal threats and attacks.
Vulnerability Assessment is the process of identifying,
quantifying, and prioritizing the vulnerabilities of the components
of IT infrastructure.
As applications move to the Web, into a server based
environment, it becomes increasingly important to be able to
gauge the performance and load capability of an application.
Stress testing involves testing the web-applications ability to
handle the load/stress resulting from increase in hits, which
Denial of Service
Testing
<<Company Name>>
maybe a result of sudden change affecting the <<Company

Name>> business activity directly.
A very serious and significant threat that web applications face is
from DoS attacks. In this attack the attacker sends so many
packets to a web site that it cannot service the legitimate users
that are trying access it. This leads to denial of service to the
legitimate users, thus affecting the business directly. So,
assessment needs to be carried out to check for <<Company
Name>> preparedness to face such an attack.

Sample WAPT Report V1.4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sample WAPT Report V1.4

Uploaded by

Copyright:

Available Formats

WEB APPLICATION

Penetration Testing Report

Penetration Testing Report

CAPTCHA NOT IMPLEMENTED................................................................................80

3 OWASP TOP TEN 2013....................................................................... 112

Penetration Testing Report

DOCUMENT SUBMISSION DETAILS

DOCUMENT DISTRIBUTION LIST

Penetration Testing Report

NII CONTACT DETAILS

Manager Security Assessment

Penetration Testing Report

Penetration Testing Report

Performed broad scans to identify potential areas of exposure and services

Penetration Testing Report

Penetration Testing Report

In this approach we only know the URL of the

Penetration Testing Report

Business Risk based approach not only focuses

Penetration Testing Report

Penetration Testing Report

Open Web Application Security Project Framework (OWASP)

Penetration Testing Report

1.8 SUMMARY OF FINDINGS

Penetration Testing Report

1.9 TABULAR SUMMARY

1.10 GRAPHICAL SUMMARY

Overall Vulnerability Graph

Penetration Testing Report

1.11 SEVERITY RATING

Penetration Testing Report

Any vulnerability classified as easy would be straightforward to exploit. There could

Penetration Testing Report

Penetration Testing Report

F IGURE 1: SQL E RROR ON P ARAMETER "L OGIN ID"

F IGURE 2: SQL I NJECTION E RROR G ENERATED B Y A PPLICATION

Penetration Testing Report

F IGURE 3: E XTRACTING D ATABASE N AME USING SQL I NJECTION

F IGURE 4: W EB S ERVICE SQL A NALYZER

Penetration Testing Report

2. Use Parameterized Queries

Penetration Testing Report

SqlConnection con = new

Penetration Testing Report

3. Use Parameterized Stored Procedures

Penetration Testing Report

2.1.2 UNRESTRICTED FILE UPLOAD

F IGURE 5 U PLOADING A M ALICIOUS FILE S TEP 1

Penetration Testing Report

F IGURE 6: UPLOADING A MALICIOUS FILE STEP 2

F IGURE 7: UPLOADING A MALICIOUS FILE STEP 3

Penetration Testing Report

Penetration Testing Report

F IGURE 8: C ONNECTION STRING IN WEB.CONFIG

Encryption key was found to be hardcoded in the source code.

string filepath = "";

Penetration Testing Report

Below is recommendation for the derived finding

Penetration Testing Report

Penetration Testing Report

2.1.3 APPLICATION ALLOWS REPLAY OF AUTHENTICATION TOKEN

F IGURE 9: T OKEN G ENERATION

Penetration Testing Report

F IGURE 11: SUCCESSFUL LOGIN WITH THE TOKEN