Security Testing – White Paperapi.ning.com/.../ZenQASecuritytestingwhitepaper.pdf · Need for Security Testing ... Identify threats in data flows : c) Identify threats in use cases

Security Testing – White Paper

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


1. Introduction

In today’s 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 product’s development are discovered. Gartner recommends security testing for products whose development is outsourced.


2. Need for Security Testing

28 October 2007 - Art.com says hacker accessed names, encrypted credit cards 10 October 2007 - 3,000 records were exposed and 20 actually stolen at Commerce Bank, a small bank in Central USA 09 October 2007 - Information including birth date and social security number of 1400 students who enrolled online to the Montana State University has been stolen by hackers 18 September 2007 - Vertical Web Media, publisher of Internet Retailer magazine, suffered a security breach and credit card information of readers had been stolen

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 just the tip of the ice berg and many such incidents have been reported from time to time. Incidents like this and many others have resulted in loss or disclosure of personal and financial information like 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 companies to 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 credit card details, social security numbers, personal addresses, confidential client information, company’s intellectual property, financial details, etc. Compromise of the confidentiality, integrity or availability of any of the above information can cost millions of dollars in lost revenue and legal battles, 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 later stages of the development lifecycle, especially after the deployment or release phase. This is more so in security. A security flaw discovered and exploited after the web application has gone into production can prove detrimental to the organisation. The damage is multiplied if it is an e-commerce application involving financial data and credit card information.


3. Security Testing Framework


3.1 THREAT ANALYSIS

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

The threat modelling process acts as a driver for our security testing efforts. It is recommended that 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 overview a) Identify key functionality b) Identify roles c) Identify application architecture d) Identify the technologies used

2) Decompose the system a) Identify trust levels and trust boundaries b) Identify assets c) Identify entry points d) Identify data flows e) Identify use cases f) Identify security mechanisms


3) Threat enumeration

a) Identify common threats and attacks b) Identify threats in data flows c) Identify threats in use cases d) Identify threat entry points e) Identify impacted assets

4) Document the threat profile


3.1.1 Application Overview In order to determine the threats to a Web Application, it is essential to study high level Architecture and functionality of the application. At a minimum, testers should have a general understanding of the key functionality of the application and familiarity with the defined user roles. An understanding of the technical implementation and architecture is also useful and can be gained from design or technical documentation. Having an understanding of the key functions of the application simplifies the system decomposition 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 and technical details may narrow the area of testing required, depending on the implementation choices made with regard to platforms, frameworks and other factors. The application overview is commonly captured in diagrammatic form such as a module or deployment diagram. It should be updated as the system is decomposed and new components are discovered. The identified threats can also be placed on the diagram with the affected components indicated.


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 ease with which threats can be discovered improves and the completeness of the analysis will be increased. The following elements of the web service application are to be broken out to assist threat enumeration: Assets - The assets of a system are the elements that hold value and need to be protected from unauthorised access and damage. The identification of assets is a necessary step in threat modelling to determine the targets of potential attacks and also to assess the impacts of a successful attack. Entry points - 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 flows - Data flows represent the paths that web service requests and responses take between client and server. It is necessary to identify data flows to grasp the interactions of the Web Application with external entities. As data moves between nodes and across trust boundaries, it must be properly validated and protected. Use cases - Functional use cases are another source of information that can be used to derive potential threats to the web service. Use cases can be analysed for ways in which functionality can be invoked without authorisation or malicious data inserted


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 the attacker 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 who maliciously changes data is often much harder to detect, and does much more damage, than a smash-and-grab Web site defacer or disk reformatted. Why? First, you might not find the modified data until some time has passed; once you find one tampered item, you’ll have to thoroughly check all 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 one of the participants. Non-repudiation means that it can be verified that the sender and the recipient were, in fact, the parties who claimed to send or receive the message, respectively Information Disclosure - Information disclosure means that an attacker can gain access, without permission, to data that the owner doesn’t want him or her to have. Denial of service (DoS) - DoS means an explicit attempt to prevent legitimate users from using a service or system. It involves the overuse of legitimate resources. You can stop all such attacks by removing the resource used by the attacker, but then real users can’t use the resource either. Elevation of privilege – 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 added to the Administrators group


Also, the vulnerabilities listed in the ‘Top 10 vulnerabilities of the year’ will be focused. Following are 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 supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.

2 Injection Flaws

Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.

3 Malicious File Execution

Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.

4 Insecure Direct Object Reference

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access 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 hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.

6 Information Leakage and Improper Error Handling

Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.

7 Broken Authentication and Session Management

Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.

8 Insecure Cryptographic Storage

Web applications rarely use cryptographic functions properly to 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 when it is necessary to protect sensitive communications.

10 Failure to Restrict URL Access

Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

http://www.owasp.org/index.php

http://www.owasp.org/index.php


3.2 Planning

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

3.2.1 Test Strategy The strategy document provides an overview of the approach to be adopted for the security testing of the web application. This strategy will be used to guide project management, develop detailed test plans and to ensure that testing efforts meet business requirements. The strategy document will clearly identify high-level test objectives and provide a summary of how priority items impact the 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


3.2.2 Test Plan Test plans are documents outlining the processes for individual testing scenarios. A test plan is a document containing a logically grouped set of test cases to be executed. Test cases will typically be conducted in a designated order, as each test case may have a number of environment dependencies or setup requirements. In the test plan phase we document test cases. They can be logically derived from the threat profile and security services to be tested and should describe the aspects of the security service under test. An overview of the threats being addressed and some example inputs and procedures for assessing the vulnerability of the web application will be provided. Test cases will be updated accordingly, to reflect changes made to the web application.


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 Injection A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete 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


Reference

ID#***

Test Case

SQL Injection

Objective

Identify SQL injection vulnerabilities

Threat

Spoofing Tampering Information disclosure Denial of Service Elevation of privileges

Impacted Asset

Web Application availability Stored data System access

Test Method

Using single quote as a test value should identify most vulnerabilities in this category


Command Injection

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

Tampering Information disclosure Denial of Service Elevation of privileges

Impacted Asset

Web Application availability Stored data System access

Test Method

The standard set of potentially dangerous special characters that could be used as a starting point for testing:

“;” is a command separator that can be used to start a new command

“|” is the output stream piping character that can be used to start a new command

“<” and “>” are the input and output redirectors that can be used to pipe input to a new command

The carriage return and line feed can often be used as command separators

“:”, “,” “/” and “\” which can be used to induce directory traversal possibly enabling an attacker to execute a command other than that which is intended.


LDAP Injection

LDAP Injection (Lightweight Directory Access Protocol) is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it’s possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary command such as granting permissions to unauthorized queries, and content modification inside the LDAP tree. The same advanced exploitation techniques available 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

Spoofing Elevation of privileges

Impacted Asset

Credentials

Test Method

Identifying vulnerable LDAP parameters involves sending LDAP special characters to the web application and observing if errors occur. The base list of test characters are as follows that are common LDAP usages

[%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


XPath Injection

XPath is a language that has been designed and developed primarily to address parts of an XML document. In XPath injection testing, we test if it is possible to inject data into an application so that it executes user-controlled XPath queries. When successfully exploited, this vulnerability may allow an attacker to bypass authentication mechanisms or access information without proper authorization. Similar to SQL injection, XPath injection is most easily detected by supplying the single quote and double quote character to each web service parameter one at a time, and assessing the responses obtained. Fields vulnerable to XPath injection will cause the application to construct a syntactically invalid XPath query, due to the addition of the quote character, and an error will occur when the query 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 XPath injection vulnerabilities an errors or empty results will occur if XPath injection is possible.

Other Injection Other types of injections like Code Injection, XML Injection and more can be identified using similar techniques. We must first identify the subsystem being used and then proceed to further analyse injection possibilities. If numerous components are interacting and no information is provided about the system, such analysis may be near impossible. However, in almost all cases an injection can be revealed by providing the subsystem special characters or combinations thereof to elicit erroneous or unusual responses. It will be up to the tester to identify the characters considered “special” by the subsystem.

http://www.owasp.org/index.php/XPATH_Injection


3.3.2 Authentication & Authorization

Authentication

Security testing of the authentication component will be performed with the objective of finding areas in which the implementation does not meet specified requirements. Test cases will include forged or modified credentials, missing credentials and other inputs to induce error handling in the application. 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 credentials from 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.

Brute-force and Dictionary Attacks

These types of attacks are typically used against password authentication systems and rely on the ability to repeatedly test potential passwords against the authentication service. Brute-force attacks involve progressively testing all valid combinations of password characters in order to determine the real password for a given user account. This method will always succeed given enough time as all possible passwords will eventually be tested. Dictionary attacks are a more refined approach and involve testing a subset of the possible passwords, typically a dictionary of language words. Additional tests may include appending numbers to dictionary words, replacing letters with defined symbols and applying lowercase or uppercase modifications.

Reference

ID#***

Test Case

Brute-force and Dictionary Attacks

Objective

Assess the susceptibility of the authentication exchange to brute-force or dictionary attacks.

Threat

Spoofing Elevating Privileges

Impacted Asset

Credentials

Test Method

Check for the default passwords left by developers, automate dictionary attack using Automated tools


Missing Credentials

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

Reference

ID#***

Test Case

Missing Credentials

Objective

Identify the system response to missing credentials

Threat

Spoofing

Impacted Asset

Credentials

Test Method

Determine the element of the web application request containing user credentials and omit it from a valid request. Ensure that such requests are discarded and not processed under some generic user account


Confidentiality of Authentication 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 assists an 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

Impacted Asset

Credentials

Test Method

Attempt to capture the authentication exchange and attempt to derive any information that may be of use to an attacker. Determine if the exchange is encrypted or performed in the clear and attempt to recover usable credentials.


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 that information to circumvent the authorization mechanism. During this kind of assessment, it should be verified if it is possible to bypass the authorization schema, find a path traversal vulnerability, or find ways to escalate the privileges assigned to the tester. 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.


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 XSS into the client side scripting

Threat

Spoofing Information Disclosure DOS attacks Elevation of Privileges

Impacted Asset

Credentials Sessions Stored data

Test Method

Attempt to insert and store XSS code with the input data and then obtain valuable data as an unauthorized user


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 forgery on 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 as an authenticated user,

1. Build an html page containing the http request referencing url u (specifying all relevant parameters; in case of http GET this is straightforward, while to a POST request you need to resort to 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


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 the operations 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

Sessions Stored data

Test Method

Testing for Session Management includes following scenarios,

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

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

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


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 and detects bugs. The data-generation part is made of generators, and vulnerability identification relies on 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 link injected 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 identified

2. Inject the Fuzz Vectors


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 documented or reported.

At the end of the Test execution phase, following two reports will be prepared detailing each finding 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 respective Defect Tracking system (is specified by the client) or a detailed defect report will be sent to the client.

Documents

Security Testing – White Paperapi.ning.com/.../ZenQASecuritytestingwhitepaper.pdf · Need for Security Testing ... Identify threats in data flows : c) Identify threats in use cases