zenqa-securitytestingwhitepaper

8/7/2019 ZenQA-Securitytestingwhitepaper

1/27

SecurityTestingWhitePaper


2/27

Security Testing White Paper 2 | P a g e

Table of Contents

1. Introduction.......................................................................................................3

2. Need for Security Testing ......................................................................................4

3. Security Testing Framework ...................................................................................5

3.1 THREAT ANALYSIS ...........................................................................................6

3.1.1 Application Overview..................................................................................8

3.1.2 System Decomposition ................................................................................9

3.1.3 Identify Threats ...................................................................................... 10

3.2 Planning..................................................................................................... 12

3.2.1 Test Strategy ......................................................................................... 12

3.2.2 Test Plan .............................................................................................. 13

3.3 Test Execution ............................................................................................. 14

3.3.1 Injection Flaws ....................................................................................... 14

3.3.2 Authentication & Authorization ................................................................... 19

3.3.3 Cross Site Scripting (XSS) ........................................................................... 23

3.3.4 Cross Site Request Forgery (CSRF) ................................................................ 24

3.3.5 Session Management................................................................................. 25

3.3.6 Fuzzing................................................................................................. 26

4. Reporting..................................................................................................... 27

4.1 High-Level Analysis Report............................................................................ 27

4.2 Detailed Defect Report ................................................................................ 27


3/27


1. Introduction

In todays world, the number and variety of threats to IT systems are multiplying daily, as is

the number of security products and services to address them. Businesses that trade electronically

are particularly vulnerable to risks such as fraud or breaches of confidentiality, causing loss of

assets and damage to their reputation. For these companies, information and transactions need to

be protected by means appropriate to their value and their potential for consequential loss.

Getting a security test done for a product, improves software quality and aids customers by

reducing development and maintenance costs as the product is shipped with minimal security

issues. Also, security flaws created during the products development are discovered. Gartner

recommends security testing for products whose development is outsourced.


4/27


2. Need for Security Testing

28 October 2007 - Art .com says hacker accessed names, encrypt ed credit cards

10 October 2007 - 3,000 r ecords were exposed and 20 actually st olen at Commerce Bank, asmal l bank in Cent ral USA

09 October 2007 - Informati on including birt h date and social securi t y number of 1400students who enrol led onli ne t o the Montana St at e Universi t y has been st olen by hackers

18 September 2007 - Vert ical Web Media, publi sher of Int ernet Retai ler magazine, suf fered a

securi t y br each and credit card informati on of readers had been st olen

Source - http://www.webappsec.org/projects/whid/list_year_2007.shtml

The above is a list of notable incidents that took place in a span of two months in 2007. This is justthe tip of the ice berg and many such incidents have been reported from time to time. Incidentslike this and many others have resulted in loss or disclosure of personal and financial informationlike credit card numbers, personal telephone numbers, etc of many an individual.

The race to get online and gain an edge over competition, has forced many companies to take to e-

commerce on a large scale. Also, the benefits in terms of time and cost has lured many companiesto hastily set up shop online with little or no thought for the security implications of doing so.

The kind of information that is at risk of exposure due to unauthorized intrusions include creditcard details, social security numbers, personal addresses, confidential client information,companys intellectual property, financial details, etc. Compromise of the confidentiality, integrityor availability of any of the above information can cost millions of dollars in lost revenue and legalbattles, not to mention the erosion in goodwill, reputation and client base.

It is a well known fact that the cost of finding a bug is manifold when it is discovered in the laterstages of the development lifecycle, especially after the deployment or release phase. This is moreso in security. A security flaw discovered and exploited after the web application has gone intoproduction can prove detrimental to the organisation. The damage is multiplied if it isan e-commerce application involving financial data and credit card information.


5/27


3. Security Testing Framework


6/27


3.1 THREAT ANALYSIS

Our Threat analysis includes a four level Threat Modelling process where we analyse thearchitecture of the application, identify areas where there is a possibility for exploitation anddocument them.

The threat modelling process acts as a driver for our security testing efforts. It is recommendedthat a thorough threat modelling process be completed before actual security testing begins.Following are the different phase in our Threat Model,

1) Create an application overviewa) Identify key functionality

b) Identify rolesc) Identify application architectured) Identify the technologies used

2) Decompose the systema) Identify trust levels and trust boundariesb) Identify assetsc) Identify entry pointsd) Identify data flowse) Identify use casesf) Identify security mechanisms


7/27


3) Threat enumerationa) Identify common threats and attacksb) Identify threats in data flows

c) Identify threats in use casesd) Identify threat entry pointse) Identify impacted assets

4) Document the threat profile


8/27


3.1.1 Application Overview

In order to determine the threats to a Web Application, it is essential to study high levelArchitecture and functionality of the application. At a minimum, testers should have a generalunderstanding of the key functionality of the application and familiarity with the defined userroles. An understanding of the technical implementation and architecture is also useful and can begained from design or technical documentation.

Having an understanding of the key functions of the application simplifies the systemdecomposition process and makes process and data flows more readily apparent to the tester.Additionally, knowledge of user roles within the system will assist analysis of access controls andtechnical details may narrow the area of testing required, depending on the implementationchoices made with regard to platforms, frameworks and other factors.

The application overview is commonly captured in diagrammatic form such as a module ordeployment diagram. It should be updated as the system is decomposed and new components arediscovered. The identified threats can also be placed on the diagram with the affected componentsindicated.


9/27


3.1.2 System Decomposition

System decomposition involves breaking down the system into its component parts in order to gain

a deeper understanding of it. By comprehending more of the inner workings of the system, the easewith which threats can be discovered improves and the completeness of the analysis will beincreased.

The following elements of the web service application are to be broken out to assist threatenumeration:

Assets- The assets of a system are the elements that hold value and need to be protected fromunauthorised access and damage. The identification of assets is a necessary step in threatmodelling to determine the targets of potential attacks and also to assess the impacts of asuccessful attack.

Entr y point s- An entry point is an avenue for incoming data to enter the system. By definition,

entry points must exist for a Web Application to receive input and perform its purpose. However,they also provide the ability for malicious inputs and attacks to enter the system and cause damage

Data f lows- Data flows represent the paths that web service requests and responses take betweenclient and server. It is necessary to identify data flows to grasp the interactions of the WebApplication with external entities. As data moves between nodes and across trust boundaries, itmust be properly validated and protected.

Use cases- Functional use cases are another source of information that can be used to derivepotential threats to the web service. Use cases can be analysed for ways in which functionality canbe invoked without authorisation or malicious data inserted


10/27


3.1.3 Identify Threats

In this stage we identify possible threats based on STRIDE classification.

Spoofing- Spoofing covers the broad use of faked credentials to gain access to resources that theattacker is not entitled to access. If a web service inadequately verifies the credentials presented

by its users, it may be susceptible to spoofing attacks

Tampering- Tampering with data means malicious modification of data. An attacker whomaliciously changes data is often much harder to detect, and does much more damage, than asmash-and-grab Web site defacer or disk reformatted. Why? First, you might not find the modifieddata until some time has passed; once you find one tampered item, youll have to thoroughly checkall the other data on your systems to ensure that nothing else was tampered with.

Repudiation- Repudiation represents the risk that a legitimate transaction will be disowned by oneof the participants. Non-repudiation means that it can be verified that the sender and the recipientwere, in fact, the parties who claimed to send or receive the message, respectively

Informat ion Disclosure- Information disclosure means that an attacker can gain access, withoutpermission, to data that the owner doesnt want him or her to have.

Denial of servi ce (DoS) - DoS means an explicit attempt to prevent legitimate users from using aservice or system. It involves the overuse of legitimate resources. You can stop all such attacks byremoving the resource used by the attacker, but then real users cant use the resource either.

Elevati on of pri vil ege Escalation of Privileges means an unprivileged user gains privileged access.An example of privilege elevation would be an unprivileged user who contrives a way to be addedto the Administrators group


11/27


Also, the vulnerabilities listed in the Top 10 vulnerabilities of the year will be focused. Followingare the list of Top 10 vulnerabilities of the year 2007 collected from OWASP -http://www.owasp.org/index.php

S No Vulnerability Short Description

1 Cross Site Scripting (XSS) XSS flaws occur whenever an application takes user supplieddata and sends it to a web browser without first validating orencoding that content. XSS allows attackers to execute scriptin the victim's browser which can hijack user sessions, defaceweb sites, possibly introduce worms, etc.

2 Injection Flaws Injection flaws, particularly SQL injection, are common inweb applications. Injection occurs when user-supplied data issent to an interpreter as part of a command or query. The

attacker's hostile data tricks the interpreter into executingunintended commands or changing data.

3 Malicious File Execution Code vulnerable to remote file inclusion (RFI) allowsattackers to include hostile code and data, resulting indevastating attacks, such as total server compromise.Malicious file execution attacks affect PHP, XML and anyframework which accepts filenames or files from users.

4 Insecure Direct Object Reference A direct object reference occurs when a developer exposes areference to an internal implementation object, such as afile, directory, database record, or key, as a URL or formparameter. Attackers can manipulate those references toaccess other objects without authorization.

5 Cross Site Request Forgery (CSRF) A CSRF attack forces a logged-on victim's browser to send a

pre-authenticated request to a vulnerable web application,which then forces the victim's browser to perform a hostileaction to the benefit of the attacker. CSRF can be aspowerful as the web application that it attacks.

6 Information Leakage andImproper Error Handling

Applications can unintentionally leak information about theirconfiguration, internal workings, or violate privacy through avariety of application problems. Attackers use this weaknessto steal sensitive data, or conduct more serious attacks.

7 Broken Authentication andSession Management

Account credentials and session tokens are often not properlyprotected. Attackers compromise passwords, keys, orauthentication tokens to assume other users' identities.

8 Insecure Cryptographic Storage Web applications rarely use cryptographic functions properlyto protect data and credentials. Attackers use weakly

protected data to conduct identity theft and other crimes,such as credit card fraud.

9 Insecure Communications Applications frequently fail to encrypt network traffic whenit is necessary to protect sensitive communications.

10 Failure to Restrict URL Access Frequently, an application only protects sensitivefunctionality by preventing the display of links or URLs tounauthorized users. Attackers can use this weakness toaccess and perform unauthorized operations by accessingthose URLs directly.
http://www.owasp.org/index.phphttp://www.owasp.org/index.phphttp://www.owasp.org/index.phphttp://www.owasp.org/index.phphttp://www.owasp.org/index.php


12/27


3.2 Planning

Effective web application security testing requires the development of both Test Strategy and TestPlan documents. The Test Strategy document provides a high-level overview of the approach to betaken for testing, whilst the Test Plan provides further detail about how the testing should beexecuted.

3.2.1 Test Strategy

The strategy document provides an overview of the approach to be adopted for the security testingof the web application. This strategy will be used to guide project management, develop detailedtest plans and to ensure that testing efforts meet business requirements. The strategy documentwill clearly identify high-level test objectives and provide a summary of how priority items impactthe business.

Test strategy will include information on the following items, where relevant:

Web Application overview (systems and environments) Architecture diagram Roles and responsibilities Assumptions and risks Test entry and exit criteria Reporting requirements and issue escalation Defect tracking method


13/27


3.2.2 Test Plan

Test plans are documents outlining the processes for individual testing scenarios. A test plan is adocument containing a logically grouped set of test cases to be executed. Test cases will typicallybe conducted in a designated order, as each test case may have a number of environmentdependencies or setup requirements.

In the test plan phase we document test cases. They can be logically derived from the threatprofile and security services to be tested and should describe the aspects of the security serviceunder test.

An overview of the threats being addressed and some example inputs and procedures for assessingthe vulnerability of the web application will be provided. Test cases will be updated accordingly, toreflect changes made to the web application.


14/27


3.3 Test Execution

Test Execution phase includes test for Vulnerabilities against the target host. All the threats

identified from STRIDE model (Section 1.3 above) will be executed against the target web

application including Top 10 vulnerabilities.

Following are the list of Vulnerabilities that will be tested for,

3.3.1 Injection Flaws

SQL Inj ect ion

A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from theclient to the application. SQL injection attacks allow attackers to spoof identity, tamper withexisting data, cause repudiation issues such as voiding transactions or changing balances, allow thecomplete disclosure of all data on the system, destroy the data or make it otherwise unavailable,and become administrators of the database server

A successful SQL injection exploit can read sensitive data from the database, modify database data

(Insert/Update/Delete), execute administration operations on the database (such as shutdown the

DBMS), recover the content of a given file present on the DBMS file system and in some cases issue

commands to the operating system. SQL injection attacks are a type of injection attack, in which

SQL commands are injected into data-plane input in order to effect the execution of predefined

SQL commands


15/27


Reference ID#***

Test Case SQL Injection

Objective Identify SQL injection vulnerabilities

Threat SpoofingTamperingInformation disclosureDenial of ServiceElevation of privileges

Impacted Asset Web Application availabilityStored dataSystem access

Test Method Using single quote as a test value should identify most vulnerabilities inthis category


16/27


CommandInjection

The purpose of the command injection attack is to inject and execute commands specified by the

attacker in the vulnerable application. In situation like this, the application which executes

unwanted system commands is like a pseudo system shell, and the attacker may use it as any

authorized system user, however, commands are executed with the same privileges and

environment as the application has. Command injection attacks are possible in most cases because

of lack of correct input data validation, whose in addition can be manipulated by the attacker

(forms, cookies, HTTP headers etc.)

Reference ID#***

Test Case Command Injection

Objective Discover any command injection vulnerabilities that may exist

Threat TamperingInformation disclosureDenial of Service

Elevation of privileges

Impacted Asset Web Application availabilityStored dataSystem access

Test Method The standard set of potentially dangerous special characters thatcould be used as a starting point for testing:

; is a command separator that can be used to start a newcommand

| is the output stream piping character that can be used tostart a new command

are the input and output redirectors that can beused to pipe input to a new command

The carriage return and line feed can often be used ascommand separators

:, , / and \ which can be used to induce directorytraversal possibly enabling an attacker to execute a commandother than that which is intended.


17/27


LDAPInjection

LDAP Injection (Lightweight Directory Access Protocol) is an attack used to exploit web basedapplications that construct LDAP statements based on user input. When an application fails toproperly sanitize user input, its possible to modify LDAP statements using a local proxy. This couldresult in the execution of arbitrary command such as granting permissions to unauthorized queries,and content modification inside the LDAP tree. The same advanced exploitation techniquesavailable in SQL Injection can be similarly applied in LDAP Injection.

Reference ID#***

Test Case LDAP Injection

Objective Assess the Web Application susceptibility to LDAP injection

Threat SpoofingElevation of privileges

Impacted Asset Credentials

Test Method Identifying vulnerable LDAP parameters involves sending LDAP specialcharacters to the web application and observing if errors occur. Thebase list of test characters are as follows that are common LDAPusages

[%26] & = and [%7C] | = or [%21] ! = not [%7E] ~ = approx equal [%3E] > = greater than [%3C] < = less than [%2A] * = any [%3F] ? = new parameter [%28] ( = start grouping [%29] ) = end grouping [%3D] = = equal


18/27


XPathInjection

XPath is a language that has been designed and developed primarily to address parts of an XMLdocument. In XPath injection testing, we test if it is possible to inject data into an application sothat it executes user-controlled XPath queries. When successfully exploited, this vulnerability mayallow an attacker to bypass authentication mechanisms or access information without properauthorization.

Similar to SQL injection, XPath injection is most easily detected by supplying the single quote anddouble quote character to each web service parameter one at a time, and assessing the responsesobtained. Fields vulnerable to XPath injection will cause the application to construct a syntacticallyinvalid XPath query, due to the addition of the quote character, and an error will occur when thequery is processed.

Reference ID#***

Test Case XPath Injection

Objective Identify XPath injection vulnerabilities

Threat Information Disclosure

Impacted Asset Stored Data

Test Method By using single quote and forward slash characters for identify XPathinjection vulnerabilities an errors or empty results will occur if XPathinjection is possible.

OtherInjection

Other types of injections like Code Injection, XML Injection and more can be identified using similartechniques. We must first identify the subsystem being used and then proceed to further analyseinjection possibilities. If numerous components are interacting and no information is provided aboutthe system, such analysis may be near impossible.

However, in almost all cases an injection can be revealed by providing the subsystem specialcharacters or combinations thereof to elicit erroneous or unusual responses. It will be up to thetester to identify the characters considered special by the subsystem.
http://www.owasp.org/index.php/XPATH_Injectionhttp://www.owasp.org/index.php/XPATH_Injection


19/27


3.3.2 Authentication & Authorization

Authentication

Security testing of the authentication component will be performed with the objective of findingareas in which the implementation does not meet specified requirements. Test cases will includeforged or modified credentials, missing credentials and other inputs to induce error handling in theapplication.

The other aspect of testing the authentication component is to attack the authentication exchange.This typically consists of capturing a legitimate exchange and attempting to extract the credentialsfrom it necessary for accessing the application. The captured exchange (or parts thereof) can also

be replayed to the application in an attempt to impersonate the legitimate user.

Brut e-force and Dict ionary At t acks

These types of attacks are typically used against password authentication systems and rely on theability to repeatedly test potential passwords against the authentication service.

Brute-force attacks involve progressively testing all valid combinations of password characters inorder to determine the real password for a given user account. This method will always succeedgiven enough time as all possible passwords will eventually be tested.

Dictionary attacks are a more refined approach and involve testing a subset of the possiblepasswords, typically a dictionary of language words. Additional tests may include appendingnumbers to dictionary words, replacing letters with defined symbols and applying lowercase oruppercase modifications.

Reference ID#***

Test Case Brute-force and Dictionary Attacks

Objective Assess the susceptibility of the authentication exchange to brute-forceor dictionary attacks.

Threat SpoofingElevating Privileges


Test Method Check for the default passwords left by developers, automatedictionary attack using Automated tools


20/27


Missing Credent ials

A user that fails to present credentials should not be allowed access and the application shoulddiscard their request. The presence of credentials should not be assumed by the applicationprocessing logic and there should not be any form of default or backup account with applicationprivileges

Reference ID#***

Test Case Missing Credentials

Objective Identify the system response to missing credentials

Threat Spoofing


Test Method Determine the element of the web application request containing usercredentials and omit it from a valid request. Ensure that such requests

are discarded and not processed under some generic user account


21/27


Conf ident iali t y of Authent icat ion Exchange

The authentication exchange should be kept private between the two parties and this is typically

achieved by encrypting the communication. Failure to do this may disclose information that assistsan attacker in credential theft.

Reference ID#***

Test Case Confidentiality of Authentication Exchange

Objective Determine the ability to eavesdrop on the authentication exchange

Threat Information Disclosure


Test Method Attempt to capture the authentication exchange and attempt to deriveany information that may be of use to an attacker. Determine if theexchange is encrypted or performed in the clear and attempt torecover usable credentials.


22/27


Authorization

Authorization is the concept of allowing access to resources only to those permitted to use them.Testing for Authorization means understanding how the authorization process works and using thatinformation to circumvent the authorization mechanism.

During this kind of assessment, it should be verified if it is possible to bypass the authorizationschema, find a path traversal vulnerability, or find ways to escalate the privileges assigned to thetester.

Test for Authorization includes testing for following objectives,

To ensure only authorized users can perform allowed actions within their privilege level To control access to protected resources using decisions based upon role or privilege level To prevent privilege escalation attacks, for example using administration functions whilst

only an anonymous user or even an authenticated user.


23/27


3.3.3 Cross Site Scripting (XSS)

XSS attacks are essentially code injection attacks into the various interpreters in the browser.

These attacks can be carried out using HTML, JavaScript, VBScript, ActiveX, Flash, and other client-

side languages. These attacks also have the ability to gather data from account hijacking, changing

of user settings, cookie theft/poisoning, or false advertising is possible. In some cases, Cross Site

Scripting vulnerabilities can perform other functions such as scanning for other vulnerabilities and

performing a Denial of Service on your web server.

Reference ID#***

Test Case Identify XSS vulnerabilities

Objective Determine the ability to insert either Stored/DOM-Based/Reflected XSSinto the client side scripting

Threat SpoofingInformation DisclosureDOS attacks

Elevation of Privileges

Impacted Asset CredentialsSessionsStored data

Test Method Attempt to insert and store XSS code with the input data and thenobtain valuable data as an unauthorized user


24/27


3.3.4 Cross Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that

contains a malicious request. It is malicious in the sense that it inherits the identity and privileges

of the victim to perform an undesired function on the victim's behalf, like change the victim's e-

mail address, home address, or password, or purchase something. CSRF attacks generally target

functions that cause a state change on the server but can also be used to access sensitive data.

Reference ID#***

Test Case Perform CSRF vulnerabilities

Objective Determine whether it is possible to create a Cross site request forgeryon the target site

Threat Elevation of Privileges

Impacted Asset Sessions

Stored data

Test Method Assuming that the file names and extension of a website are know asan authenticated user,

1. Build an html page containing the http request referencing urlu (specifying all relevant parameters; in case of http GET thisis straightforward, while to a POST request you need to resortto some Javascript);

2. make sure that the valid user is logged on the application;3. click on the link created in step-1 and verify if the web server

executed the request


25/27


3.3.5 Session Management

Cookies are used to implement session management. In a nutshell, when a user accesses an

application which needs to keep track of the actions and identity of that user across multiple

requests, a cookie (or more than one) is generated by the server and sent to the client. The client

will then send the cookie back to the server in all following connections until the cookie expires or

is destroyed. The data stored in the cookie can provide to the server a large spectrum of

information about who the user is, what actions he has performed so far, what his preferences are,

etc. therefore providing a state to a stateless protocol like HTTP

Due to the importance of the data that they store, cookies are therefore vital in the overall

security of the application. Being able to tamper with cookies may result in hijacking the sessions

of legitimate users, gaining higher privileges in an active session, and in general influencing theoperations of the application in an unauthorized way. In this test we will check whether the cookies

issued to clients can resist a wide range of attacks aimed to interfere with the sessions of

legitimate users and with the application itself

Reference ID#***

Test Case Session Management

Objective Determine whether it is possible to break/hijack the session

Threat Elevation of Privileges

Impacted Asset SessionsStored data

Test Method Testing for Session Management includes following scenarios,

1. Collection of Cookies2. Session Tokens are collected and examined for their

randomness and uniqueness using Automation tools3. Perform Cookie reverse engineering to ensure it has following

characteristics, it is Unpredictable, Tamper resistance,Expiration, Secure flag


26/27


3.3.6 Fuzzing

Fuzz testing basically consists in finding implementation bugs using malformed/semi-malformed

data injection in an automated fashion.

A fuzzer is a program which injects automatically semi-random data into a program/stack anddetects bugs. The data-generation part is made of generators, and vulnerability identification relieson debugging tools. Generators usually use combinations of static fuzzing vectors (known-to-be-dangerous values), or totally random data. New generation fuzzers use genetic algorithms to linkinjected data and observed impact. Such tools are not public yet.

Reference ID#***

Test Case Fuzzing

Objective Determine whether it is possible to Fuzz web requests

Threat Denial of Service

Impacted Asset Stored Data

Test Method Using Manual/Automatic injection tools,1. Fuzz Vectors (Known to be dangerous values) for each

request are identified2. Inject the Fuzz Vectors


27/27

4. Reporting

This is the final and most important phase as it is here that all the findings are documented.Successful implementation of the above phases would be futile if they are not properly documentedor reported.

At the end of the Test execution phase, following two reports will be prepared detailing eachfinding and assigning a suitable severity level to them.

4.1 High-Level Analysis Report

After the execution phase a High level analysis report will be created that reflects issues reported

in the detailed defect report.

4.2 Detailed Defect Report

All the defects (vulnerabilities) identified during the Test Execution are logged into respectiveDefect Tracking system (is specified by the client) or a detailed defect report will be sent to theclient.

zenqa-securitytestingwhitepaper

Documents