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


2/12


, 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


3/12


, 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.


4/12


, 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.


5/12


, 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


6/12


, 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.



7/12


, 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.


8/12


, 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.



9/12


, 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.


10/12


, 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.


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.



11/12


, 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


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


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.


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/

Documents

Candidate Dashboard WASA Report July 2012