Candidate Dashboard WASA Report July 2012
-
Upload
varshadeore143 -
Category
Documents
-
view
214 -
download
0
Transcript of Candidate Dashboard WASA Report July 2012
-
7/31/2019 Candidate Dashboard WASA Report July 2012
1/12
Confidential - Copyright Kenexa
, 2012
343 Winter Street
Waltham, MA 02451
United States
Tel: 781.530.5000
BP Candidate DashboardWeb Application Security Assessment
Conducted by:
Kenexa Information SecurityJuly 2012
-
7/31/2019 Candidate Dashboard WASA Report July 2012
2/12
Confidential - Copyright Kenexa
, 2012 2
ContentsExecutive Summary .......................................................................................................................................3
Methodology .................................................................................................................................................3
Risk Rating Definitions ...................................................................................................................................4
Detailed Findings and Recommendations .....................................................................................................5
1. Confirmed Blind SQL Injection ...............................................................................................................5
2. Session Identifier Not updated ..............................................................................................................6
3. Apache Chunked Encoding Overflow ....................................................................................................7
4. Possible PHP Source Code Disclosure....................................................................................................8
5. SSL/Encryption Not Enforced ................................................................................................................9
6. Cross-Site Request Forgery ................................................................................................................. 10
7. Directory Listings with Config/Admin Pages ...................................................................................... 10
8. Apache specific web directories listings ............................................................................................. 12
9. Common Documentations Text Files ................................................................................................. 12
10. System File Path Disclosure ............................................................................................................ 12
-
7/31/2019 Candidate Dashboard WASA Report July 2012
3/12
Confidential - Copyright Kenexa
, 2012 3
Executive SummaryDuring the time frame ofJune 15thJuly 3rd, a web application security assessment (WASA) of
theBPCandidate Dashboardwas conducted. The overall objective assessment was to determinethe security risks found in theBP Candidate Dashboard. The objectives of this vulnerability
assessment were to evaluate the:
Security-related controls embedded in the web application.
To determine whether adequate security controls are in place.
The security controls of theBP Candidate Dashboardwith respect to the Information Security
policies were found toneed improvement. Several high severity items were discovered that should
be addressed as soon as possible. Matters warranting managements attention and details of the
finding are presented in the Detailed Findings section of this report.
A sample of the items observed were: blind SQL injection, cross site request forgery, session id
values not being updated adequately, lack of site wide encryption, directory listings containingsensitive files, local system path disclosure and generic information leaking related to the host web
server and associated applications.
Supporting detailed reports from the automated scanning tools are available and will be distributed
to those with a need to know or upon request. These reports should be leveraged to help identify all
instances of vulnerabilities outlined within this document
Methodology
To perform the Web Application testing we assumed the role of an authenticated user of the system.
We used publicly-available tools and information to identify vulnerabilities in the web application.
Our manual testing was additionally supplemented by automated scanners such as Proxy Strike,Fierce DNS Scanner, Nessus, Burp Suite, HP Web Inspect, and IBM App Scan.
The goal of the web application assessment is to perform a careful inspection of the application toidentify potential threats both from a technical or administrative standpoint. In performing these
tests we attempted to identify weaknesses in areas including client-side controls, business logic
flaws, authentication, session management, access controls, input validation, and web server or
operating system flaws.
-
7/31/2019 Candidate Dashboard WASA Report July 2012
4/12
Confidential - Copyright Kenexa
, 2012 4
Risk Rating DefinitionsThe following general definitions are used to rate the risk for each vulnerability.
Risk:
High Risk (H): A vulnerability that is exploitable locally or remotely that could lead to
sensitive information being revealed or a complete system compromise.
Medium Risk (M): A vulnerability that is more difficult to exploit due to requiring a
combination of steps in order to exploit, or detailed knowledge of the system in order to
compromise the system or obtain sensitive information.
Low Risk (L): A vulnerability that may reveal system information that an attacker may use
for reconnaissance. This may also be a vulnerability that would require privileged access
from a trusted local user, or a non-exploitable issue that does not meet industry best
practices.
-
7/31/2019 Candidate Dashboard WASA Report July 2012
5/12
Confidential - Copyright Kenexa
, 2012 5
Detailed Findings and Recommendations
1. Confirmed Blind SQL Injection | Risk: H|Description: Blind SQL Injection vulnerabilities have been confirmed in the web application.MySQL was detected as the backend database. A Database named 'dashboard_demo' was
detected on the remote system.
SQL injection is a method of attack where an attacker can exploit vulnerable code and the type
of data an application will accept, and can be exploited in any application parameter that
influences a database query. Examples include parameters within the url itself, post data, or
cookie values.
Normal SQL Injection attacks depend in a large measure on an attacker reverse engineering
portions of the original SQL query using information gained from error messages. However,your application can still be susceptible to Blind SQL injection even if no error message is
displayed.
Vulnerable Pages/Parameters:
POST /user/login/index/3 HTTP/1.1Referer: http://candidatedashboard.collabor.com:80/user/login/home
Content-Type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest
Accept: */*
Content-Length: 82
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Pragma: no-cache
Host: candidatedashboard.collabor.com
Connection: Keep-Alive
Cookie:
CustomCookie=WebInspect80412ZX223415C1AFAD43AD9ECE215C352E575AYF61B ;PHPSESSID=ljj9aktredbb9da
ifu2hmlhhc2
video_id=1%09AND%09(select%09ASCII(SUBSTR(schema()%2c15%2c1)))%09%3c0%09Or%093%3d6
GET/user/login/loadvideo/?q=1%09AND%09(select%09ASCII(SUBSTR(schema()%2c15%2c1)))%09%3c0%09Or%093%3d6 HTTP/1.1Referer: http://candidatedashboard.collabor.com:80/user/login/home
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Accept: */*
Pragma: no-cache
Host: candidatedashboard.collabor.com
Connection: Keep-Alive
Cookie:
CustomCookie=WebInspect80412ZX223415C1AFAD43AD9ECE215C352E575AYF61B ;PHPSESSID=e37e8cjo4k664
nv69tlbgfhot0
-
7/31/2019 Candidate Dashboard WASA Report July 2012
6/12
Confidential - Copyright Kenexa
, 2012 6
Impact: If successful, SQL Injection can give an attacker access to backend database contents,the ability to remotely execute system commands, or in some circumstances the means to take
control of the server hosting the database. Recommendations include employing a layered
approach to security that includes utilizing parameterized queries when accepting user input,
ensuring that only expected data is accepted by an application, and hardening the database serverto prevent data from being accessed inappropriately.
Solution: Each method of preventing SQL injection has its own limitations. Therefore, it is wise
to employ a layered approach to preventing SQL injection, and implement several measures to
prevent unauthorized access to your backend database. The following are recommended coursesof action to take to prevent SQL Injection and Blind SQL Injection vulnerabilities from being
exploited in your web application.
Parameterized Queries, Consistent Error Messaging Schemes,Strong SA Password Policy, input
validation via white listing method. White listing is defined as only accepting specific account
numbers or specific account types for those relevant fields, or only accepting integers or lettersof the English alphabet for others.
Team Response:
2. Session Identifier Not updated | Risk: H|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 beutilized 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 beenfixed, the attacker waits for the user to login, and then uses the predefined session ID value toassume the user's online identity.
Vulnerable Pages/Parameters:
-
7/31/2019 Candidate Dashboard WASA Report July 2012
7/12
Confidential - Copyright Kenexa
, 2012 7
Impact: It is possible to steal or manipulate customer session and cookies, which might be used
to impersonate a legitimate user, allowing the attacker to view or alter user records, and to
perform transactions as that user.Solution: Always generate a new session to which the user will log in if successfully
authenticated. Prevent user ability to manipulate session ID. Do not accept session IDs provided
by the user's browser at login.
Team Response:
3.Apache Chunked Encoding Overflow | Risk: H|Description: A chunked encoding buffer overflow vulnerability was detected on the remote
Apache server.
-
7/31/2019 Candidate Dashboard WASA Report July 2012
8/12
Confidential - Copyright Kenexa
, 2012 8
Per RFC 2068, section 3.6 web servers are required to permit a client to break up a single request
into multiple chunks of sections of a specific length. The Apache HTTP Server in use has a
software flaw relating to correctly determine the size of the incoming data sections/chunks.Vulnerable Pages/Parameters:
Impact: If successfully exploited an attacker may be able to remotely execute arbitrary
commands on the remote system running the vulnerable version of Apache.
Solution: Upgrade the Apache HTTP Server that is no longer vulnerable to this issue.
Team Response:
4. Possible PHP Source Code Disclosure | Risk: H|Description: PHP source code was detected in the HTTP response data.
Vulnerable Pages/Parameters:
-
7/31/2019 Candidate Dashboard WASA Report July 2012
9/12
Confidential - Copyright Kenexa
, 2012 9
Impact: Obtaining PHP source code on a system allows an attacker to view the logic of the
script and extract extremely useful information such as code bugs or logins and passwords.
Solution: Recommendations include removing this script from the web server and moving it to a
location not accessible from the Internet
Team Response:
5. SSL/Encryption Not Enforced | Risk: M|Description: During the assessment, it was detected that the site does not use an encryptedconnection (SSL) to protect sensitive information. Any information sent to the server as clear
text, may be stolen and used later for identity theft or user impersonation.
In addition, several privacy regulations state that sensitive information such as user credentials
will always be sent encrypted to the web site.
Impact: It may be possible to steal sensitive data such as credit card numbers, social security
numbers etc. that are sent unencrypted.
Credentials and other data supplied during a login request is vulnerable to interception.
-
7/31/2019 Candidate Dashboard WASA Report July 2012
10/12
Confidential - Copyright Kenexa
, 2012 10
Solution: Install an SSL certificate to the web server. Ensure that all requests, not just login
requests or other sensitive requests, are sent via an encrypted connection.
Team Response:
6. Cross-Site Request Forgery | Risk: M|Description: Cross-Site Request Forgery (CSRF) is an attack that allows a hacker to perform an
action on the vulnerable site on behalf of the victim. The attack is possible when the vulnerable
site does not properly validate the origin of the request.
Vulnerable Pages/Parameters:
URL: http://candidatedashboard.collabor.com/user/login/
Entity: login
Impact: It is possible to steal or manipulate customer session and cookies, which might be usedto impersonate a legitimate user, allowing the hacker to view or alter user records, and to
perform transactions as that user
Solution: In order to avoid CSRF attacks, every request should contain a unique identifier,which is a parameter that an attacker cannot guess.
Team Response:
7. Directory Listings with Config/Admin Pages | Risk: M|Description: Configuration/Administrative Directories were discovered that appear to directly
manipulate the back end systems without authentication.
Vulnerable Pages/Parameters:
-
7/31/2019 Candidate Dashboard WASA Report July 2012
11/12
Confidential - Copyright Kenexa
, 2012 11
Impact: It is possible to retrieve information about the site's file system structure, which may
help the attacker to map the web site. The directories may also contain specific informationrelating to the database configuration, request log files, and other information that should be
protected.
Solution: If the forbidden resource is not required, remove it from the site.If possible, issue a "404 - Not Found" response status code instead of "403 - Forbidden". This
change will obfuscate the presence of the directory in the site, and will prevent the site structure
from being exposed
-
7/31/2019 Candidate Dashboard WASA Report July 2012
12/12
C fid ti l C i ht K
2012 12
Team Response:
8.Apache specific web directories listings| Risk: L|Description: It is possible to view and download the contents of certain web application virtualdirectories, which might contain restricted files
Vulnerable Pages/Parameters:
http://candidatedashboard.collabor.com/images/
http://candidatedashboard.collabor.com/scripts/
http://candidatedashboard.collabor.com/styles/
Impact: An attacker may be able to determine the version of Apache, or the file structure of thw
web site to leverage in later multi-staged attacks.
Solution: Disable multiviews in the Apache httpd.conf. Upgrade Apache and or obfuscate the
directories and related HTTP response data.
Team Response:
9. Common Documentations Text Files | Risk: L|Description: A documentation file was found. The danger in having a documentation file
available is that it reveals to attackers what type of software you are using and often the specific
version information, or a location from where the attacker could download the software itself.Recommendations include removing this file from the production server.
Vulnerable Pages/Parameters:http://candidatedashboard.collabor.com/icons/README http://candidatedashboard.collabor.com/livechat/README
Impact: The danger in having a documentation file available is that it reveals to attackers what
type of software you are using and often the specific version information, or a location from
where the attacker could download the software itse
Solution: Recommendations include removing this file from the production server.
Team Response:
10.System File Path Disclosure | Risk: L|Description: Complete local system file paths were encountered while testing.
Vulnerable Pages/Parameters:
GET /livechat/js/source/build.xml HTTP/1.1Host: candidatedashboard.collabor.com
Impact: Fully qualified server path names allow an attacker to know the file system structure of
the web server, which is a baseline for many other types of attacks to be successful
Solution: Recommendations include adopting a consistent error handling scheme and
mechanism that prevents fully qualified path names from being displayed
Team Response:
http://candidatedashboard.collabor.com/images/http://candidatedashboard.collabor.com/images/http://candidatedashboard.collabor.com/scripts/http://candidatedashboard.collabor.com/scripts/http://candidatedashboard.collabor.com/styles/http://candidatedashboard.collabor.com/styles/http://candidatedashboard.collabor.com/icons/READMEhttp://candidatedashboard.collabor.com/icons/READMEhttp://candidatedashboard.collabor.com/livechat/READMEhttp://candidatedashboard.collabor.com/livechat/READMEhttp://candidatedashboard.collabor.com/livechat/READMEhttp://candidatedashboard.collabor.com/icons/READMEhttp://candidatedashboard.collabor.com/styles/http://candidatedashboard.collabor.com/scripts/http://candidatedashboard.collabor.com/images/