Security Testing Concepts and Definitions

"With so many techniques and approaches to testing the security of web

applications it can be difficult to understand which techniques to use and when

to use them. Experience shows that there is no right or wrong answer to the

question of exactly what techniques should be used to build a testing

framework. In fact all techniques should probably be used to test all the areas

that need to be tested." - Open Web Application Security Project

2015

Sarah Goldberg

Restaurant.com

Version 1.0

1 | P a g e

Table of Contents

Security Testing Introduction...............................................................................................................................................................3

Areas of Focus .............................................................................................................................................................................................3

Network Security...................................................................................................................................................................................3

System Software Security .................................................................................................................................................................3

Client-Side Application Security ....................................................................................................................................................3

Server-Side Application Security...................................................................................................................................................3

Attack Types .................................................................................................................................................................................................4

(Denial-of-Service/Distributed Denial of Service Attacks (DoS/DDoS) .....................................................................4

(IP Spoofing to Bypass Network Security)................................................................................................................................4

(Man in the Middle Attacks) ............................................................................................................................................................4

(Back Door Attacks) .............................................................................................................................................................................4

(DNS Poisoning) ....................................................................................................................................................................................4

(Replay Attack) .......................................................................................................................................................................................4

(Weak Encryption Keys) .....................................................................................................................................................................4

(Social Engineering) .............................................................................................................................................................................4

(Password Cracking) ............................................................................................................................................................................5

(Dictionary Attack)................................................................................................................................................................................5

(Brute Force Attack) .............................................................................................................................................................................5

(Software Vulnerability Attack) ......................................................................................................................................................5

(Buffer Overflow Attack) ....................................................................................................................................................................5

(Remote code Execution Attack) ...................................................................................................................................................5

(SQL Injection Attack) .........................................................................................................................................................................5

(Cross Site Scripting Attack) ............................................................................................................................................................5

Injection flaws (SQL Injection) ........................................................................................................................................................5

Broken Authentication and Session Management ..............................................................................................................7

Cross-Site Scripting (XSS) .................................................................................................................................................................7

Cross-Site Request Forgery (CSRF) ..............................................................................................................................................9

Insecure Direct Object References ............................................................................................................................................ 10

2 | P a g e

Security Misconfiguration.............................................................................................................................................................. 12

Sensitive Data Exposure (SSL) ...................................................................................................................................................... 12

Unvalidated Redirect and Forwards ......................................................................................................................................... 13

Security Testing Attributes ................................................................................................................................................................. 14

Authentication ..................................................................................................................................................................................... 14

Authorization ....................................................................................................................................................................................... 15

Availability ............................................................................................................................................................................................. 15

Confidentiality ..................................................................................................................................................................................... 16

Integrity................................................................................................................................................................................................... 16

Non-repudiation ................................................................................................................................................................................ 17

Security Testing Techniques.............................................................................................................................................................. 17

White-Hat Testing (Functional Security Testing) ............................................................................................................... 17

Black-Hat Testing (Adversarial Security Testing) ............................................................................................................... 17

Vulnerability Assessment .......................................................................................................................................................... 17

Penetration Testing ...................................................................................................................................................................... 17

Risk Assessment............................................................................................................................................................................. 18

Risk-Based Testing........................................................................................................................................................................ 18

Fuzz Testing ..................................................................................................................................................................................... 18

Source Code/Static Analysis .................................................................................................................................................... 18

Injection Testing ............................................................................................................................................................................ 18

Security Testing Approach ................................................................................................................................................................. 19

Security Testing Tools........................................................................................................................................................................... 20

Works Cited ............................................................................................................................................................................................... 21

3 | P a g e

Security Testing Introduction

Security Testing is used to determine that an information system protects data and maintains its

intended functionality.

The purpose of the security test is to discover the vulnerabilities of the web application so that the

developers can then remove these vulnerabilities from the application and make the web application

and data safe from unauthorized actions.

Failures in the software security system can be serious especially when not detected, thereby resulting

in a loss or compromise of information without the knowledge of that loss. For a Business this can

mean:

Loss of customer trust.

Disturbance of online means of revenue generation/collection.

Website downtime, time loss and expenditures in recovering from damage (reinstalling services,

restoring backups, etc.)

Cost associated with securing web applications against future attacks.

Related legal implications and fees for having lax security measures in place.

These implications can be avoided by performing security testing both prior to the system going into

operation and after the system is in operation (regression testing).

Areas of Focus

For websites and applications, like Restaurant.com, security testing focus can be broken down into four

areas.

Network Security – looks for vulnerabilities in the network infrastructure (resources and policies)

System Software Security – assesses weaknesses in the operating system, database system, and

other software used by the application depends on

Client-Side Application Security – works to ensure that the client1 cannot be manipulated.

Server-Side Application Security – involves making sure that the server code and its technologies

are tough enough to fend off any intrusion or attack.

1 Client can refer to the user, browser, or tool which uses the application

4 | P a g e

Attack Types

There are many types of attacks, malicious2 or otherwise, which security testers are looking for. Some of

these top concerns or attacks are listed below along with how they relate to Restaurant.com.

(Denial-of-Service/Distributed Denial of Service Attacks (DoS/DDoS)

(IP Spoofing to Bypass Network Security)

(Man in the Middle Attacks)

(Back Door Attacks)

(DNS3 Poisoning)

Typically with unsecured dynamic updates, any computer can create records on your DNS server which

leave you open to malicious activity. To keep the DNS server secure, secure DNS makes it so that only

members of an Active Directory 4domain can create records on the DNS server.

(Replay Attack)

(Weak Encryption Keys)

(Social Engineering)

Social Engineering plays on people’s ignorance and fears.

2 motivated by wrongful, vicious, or mischievous purposes 3 Domain Name System, an internet service that translates domain names into IP addresses. 4 An implementation of internet standard directory and naming protocols that uses a database engine for

transactional support. It supports a variety of application programming interface standards.

5 | P a g e

A type of Social Engineering is a Virus Hoax, a message warning the recipient of a non-existent threat.

An example of this might be a chain email that tells the recipient to forward it to all their friends.

(Password Cracking)

(Dictionary Attack)

(Brute Force Attack)

(Software Vulnerability Attack)

(Buffer Overflow Attack)

(Remote code Execution Attack)

(SQL Injection Attack)

(Cross Site Scripting Attack)

Injection flaws (SQL Injection)

It can happen when unfiltered data is passed to the SQL server (SQL injection), to the browser (XSS

injection), or anywhere else. Injection can result in data loss or corruption, lack of accountability, or

denial of access. Injection can sometimes lead to complete host takeover.

6 | P a g e

To prevent injection flaws, the inputs should be properly filtered in the command or query. This would

separate untrusted data from trusted data, only returning results for trusted data. Or use the

frameworks built in filtering functions.

Restaurant.com could be vulnerable to this on our account sign in page, for example. Injection could

allow User Names, Passwords, Saved Credit Card Information, and other user information.

(Veracode, 2015)

Figure 1_http://www.veracode.com/security/sql-injection

7 | P a g e

Broken Authentication and Session Management

These types of attacks are anonymous, generated to try and retrieve passwords, user IDs, account

details and other information. Typically administrative or privileged accounts are targeted. Once

successful, the attacker can do anything the user could do. Some of these attacks happen because user

credentials aren’t protected, can be guessed, or can be overwritten via account creation, change

password, forgot password, etc. Session ID’s can be hijacked if the ID is exposed in the URL, session

doesn’t timeout, session tokens don’t invalidate during logout. In order to prevent this credentials

should be encrypted.

Restaurant.com has many of these bases covered already. The session ID’s implement unique token

values, as seen in the image below. RDC makes use of session timeouts (24h currently, I believe),

requiring users to sign back into their account after non-activity period of time. The forgot-password

process makes use of tokens as well sent via email in a multi-step process.

Figure 2_Example from Restaurant.com, my account-my certificates page, showing token values and session

expirations

Cross-Site Scripting (XSS)

Cross-Site scripting occurs when a web application gathers malicious data from a user. The data is

usually gathered in the form of a hyperlink which contains malicious content within it. The user will

most likely click on this link from another website, instant message, or simply just reading a web board

or email message. After the data is collected by the web application, it creates an output page for the

user containing the malicious data that was originally sent to it, but in a manner to make it appear a s

8 | P a g e

valid content from the website. This is essentially a type of Injection flaw (JavaScript, VBScript, ActiveX,

HTML, or Flash).

The impact of cross-site scripting can cause issues ranging from misleading content to malware5 to up

to full data loss. To prevent this, web applications need to validate inputs. This will allow unrecognized

inputs to be targeted and flagged as specious.

Being that Restaurant.com has many web pages and applications (both internal and external) we need

to be especially vigilant against this type of attack. I believe consistent use of our regression testing and

reporting from customer service helps to keep an eye on issue like this.

(amicon, 2010)

Figure 3_http://www.amicontech.com/blog/xss-cross-site-scripting-in-ofbiz-opentaps/

5 Short for malicious software, refers to software designed specifically to damage or disrupt a system.

9 | P a g e

Cross-Site Request Forgery (CSRF)

When malicious requests are sent from a site that a user visits to another site that the attacker believes

the victim is validated against. The malicious requests are routed to the target site via the victim’s

browser, which is authenticated against the target site

A good way to prevent these types of attacks is to implement CSRF tokens. Tokens should at a

minimum be unique per user session, but can also be unique per request. By including a challenge

token with each request, the developer can ensure that the request is valid and not coming from a

source other than the user. Having session Id’s encrypted with a token and set to expire after a set time

also helps to prevent these types of attacks.

An example of this would be when a user still has an active session on Restaurant.com and in another

tab or in their history they are still logged into their PayPal account.

10 | P a g e

(Hack This , 2015)

Figure 4_https://www.hackthis.co.uk/articles/cross-site-request-forgery

Insecure Direct Object References

A direct object reference means that an internal object such as a file or database key is exposed to the

user. The problem with this is that the attacker can provide this reference and, if authorization is either

not enforced (or is broken), the attacker can access or do things that they should be restricted from.

Each location that a user can supply input and points directly to reference objects needs to be

tested. By manipulating parameter values, testers can identify the flaw and then analyze the code to

determine whether a user is able to bypass authorization and retrieve objects that are not intended for

them.

11 | P a g e

A good way to prevent this would be through the use of Obfuscation, a means for inferring security

through obscurity. A simple example people can identify with is shortened URLs. Though security is not

the intent, a URL such as http://bit.ly/1Gg2Pnn is obfuscated from what the actual URL represents.

Restaurant.com could consider using obfuscation on the URL for our Dining Certificates;

https://www.restaurant.com/account/viewcertificate/?id=282616573 . Notice that the dining

certificate ID or reference number is listed in the URL. We do have other securities in place to protect

this object but adding obfuscation would be an additional barrier to attack.

(Code Project, 2015)

Figure 5_http://www.codeproject.com/Articles/885301/be-secure-from-insecure-direct-object-reference

12 | P a g e

Security Misconfiguration

Result in incorrectly assembled safeguards for a web application. These misconfigurations typically

occur when holes are left in the security framework of an application by systems administrators, DBAs

or developers. They can occur at any level, network or client-side for example. These security

misconfigurations, such as an outdated antivirus program6, can lead an attacker right into the system

and result in a partially or even totally compromised system.

In order to prevent these misconfigurations make sure to install the latest security updates. Remove any

unnecessary features or plugins. Change the passwords and usernames for any default accounts. If the

framework has security settings make sure to read the documentation to set them to appropriate

values. These processes should be automated as much as possible, since they’ll need to repeat with

each update to the application. There are tools such as Microsoft Baseline Security Analyzer 7to help

identify these types of issues.

Restaurant.com has been steadily improving on this security aspect with our automated build-deploy

processes. Using NuGet8 to package our libraries also helps keep us protected.

Sensitive Data Exposure (SSL)

This vulnerability is about cryptography and resource protection. Best solution, don’t store sensitive

data. However since most do store some of this data, it should be encrypted at all times. Credit

card information and user passwords should never travel or be stored unencrypted, and passwords

should always be hashed.

SSL (Secure Sockets Layer) is the standard security technology for establishing an encrypted link

between a web server and a browser. This link ensures that all data passed between the web server and

browsers remain private and integral.

Restaurant.com uses SSL certificates to protect data. These certificates need to be kept up-to-date in

order to provide their full security potential.

6 A tool that searches a hard disk for viruses, then removes any that are found. If left outdated, any new vires will

not be recognized. 7 See Security Testing Tools section for more information 8 A free and open-source package manager, for the Microsoft development platform, which supports

multiple programming languages.

13 | P a g e

Figure 6_example from restaurant.com, checkout-billing page, shows partial credit card number

Unvalidated Redirect and Forwards

Web applications frequently redirect and forward users to other pages or other external websites;

however, without validating the credibility of those pages, hackers can redirect victims to phishing or

malware sites, or use forwards to access unauthorized pages or gain access to user data.

Suppose that the target site has a redirect.php module that takes a URL as a GET parameter.

Manipulating the parameter can create a URL on targetsite.com that redirects the browser to

malwareinstall.com. When the user sees the link, they will see targetsite.com/blahblahblah which

the user thinks is trusted and is safe to click. Little do they know that this will actually transfer them onto

a virus9 drop (or any other malicious) page. Alternatively, the attacker might redirect the browser to

targetsite.com/deleteprofile?confirm=1

The best way to avoid this issue is to avoid redirects and forwards altogether. As this is not

always a realistic option, adding filtering to input helps along with having a static list of valid

locations which are redirected to. Testing efforts can also help identity vulnerable areas. Some

of these efforts include:

9 A program or piece of code, that is loaded onto your computer without your knowledge, and runs against your

wishes.

14 | P a g e

Automated code scanning with security-aware source code analysis tools

Automated detection with website spidering or crawling tools

Manual code scanning

Manual testing

Restaurant.com could be prone to these security risks as we make use of redirects frequently

throughout our site and applications. We also send many types of emails which could be targeted.

Security Testing Attributes

Security testing, as a term, has a number of different meanings and can be completed in a number of

different ways. Understanding these concepts (or attributes) provides a solid knowledge base to then

better evaluate and pin-point security concerns within Restaurant.com. Below are the top six security

testing attributes and how to test for them:

Authentication

Authentication is the process of assuring the validity of any type of input, transmission or message.

Providing confidence that information is received by a known and validated source. An example would

be logging into My Account on Restaurant.com. RDC identifies an individual by username and

password, after authenticated; the user can access their account. If not authenticated (invalid password

or username is entered) the individual is not given access. Some other forms of authentication are; what

a person knows, such as Personal Identity Number (PIN), what a person has, such as a Physical ID Card

or Digital Certificate, and a person’s Biometric Factors (ex. fingerprints or retinal scans). When these

types of authentications are bundled together it is called multi-factor (multi-stage) authentication.

Here are a few tests which focus on authentication:

15 | P a g e

Test for user enumeration

Test for authentication bypass

Test for brute force protection

Test for Credentials Transported over an Encrypted Channel

Test password quality rules * Test remember me functionality

Test password reset and/or recovery

Test password change process

Test CAPTCHA

Test multi factor authentication

Test for logout functionality presence

Test for cache management on HTTP (ex. Pragma, Expires, Max-age)

Test for default logins

Test for user-accessible authentication history

Test for out-of-channel notification of account lockouts and successful password changes

Test for consistent authentication across applications with shared authentication schema / SSO

and alternative channels

Test for Weak security question/answer

Authorization

Determining that a requester is allowed to receive a service or perform an operation (Access control).

This is done through rights and permissions. A right authorizes a user to perform a certain action, such

as logging into a system or backing up files. Rights are assigned through local policies or active

directory group policies. Permission sets the type of access that is given to an object or object attribute,

such as the ability to read or edit an object. Permission settings are kept in an access control list (ACL).

Here are a few tests which focus on authorization:

Test for path traversal

Test for vertical Access control problems (a.k.a. Privilege Escalation)

Test for horizontal Access control problems (between two users at the same privilege level)

Test for missing authorization

Test for Insecure Direct Object References

Compare client-side and server-side validation rules

Availability

Availability is used to assure information and communications services will be ready for use when

expected. Information must be kept available to authorized persons when they need it.

16 | P a g e

Establish how session management is handled in the application (eg, tokens in cookies10, token

in URL)

Check session tokens for cookie flags (http Only and secure)

Check session cookie scope (path and domain)

Check session cookie duration (expires and max-age)

Check session termination after a maximum lifetime

Check session termination after relative timeout

Check session termination after logout

Test to see if users can have multiple simultaneous sessions

Test session cookies for randomness

Confirm that new session tokens are issued on login, role change and logout

Test for consistent session management across applications with shared session management

Confidentiality

A security measure which ensures information is accessible only for those with authorized access and to

prevent information disclosure to any party other than the intended recipients. Often ensured by

encoding information using algorithms (cryptography).

Check if data which should be encrypted is not

Check for wrong algorithms usage depending on context

Check for weak algorithms usage

Check for proper use of salting

Check for randomness functions

Integrity

Ensuring received information is preserved successfully with no alteration.

Test for integrity of data

Test Upload of Unexpected File Types

Test upload of malicious files

Check SSL Version, Algorithms, Key length

Check for Digital Certificate Validity (Duration, Signature and CN)

Check credentials only delivered over HTTPS

Check that the login form is delivered over HTTPS

Check session tokens only delivered over HTTPS

10 A piece of text stored by a user’s web browser. Text can include user’s ID, authentication, site preferences, and

shopping cart contents.

17 | P a g e

Non-repudiation

Ensuring action/communication cannot later be denied. It is usually used by form of authentication and

time stamping.

Test for lack of non-repudiation

Test ability to forge requests

Test for account lockout

Security Testing Techniques

The prime objective of security testing is to find out how vulnerable a system may be and to determine

whether its data and resources are protected from potential intruders. There are many different types of

Security testing techniques out there. These testing types can be broken down into two categories;

White-Hat Testing (Functional Security Testing) looks at security functions to make sure

they are properly implemented and operating as expected.

Black-Hat Testing (Adversarial Security Testing) looks at security testing motivated by

understanding and simulating a potential attackers approach.

The most commonly used security testing techniques used are:

Vulnerability Assessment

A process that defines, identifies, and classifies the security holes (vulnerabilities). Using this method to

assess vulnerabilities, security testers deliberately probe a network or system to discover its weaknesses.

This process provides guidelines for the development of countermeasures to prevent a genuine attack.

Penetration Testing

As stated above a vulnerability assessment simply identifies and reports noted vulnerabilities, whereas a

penetration test attempts to exploit the vulnerabilities to determine whether unauthorized access or

other malicious activity is possible. The penetration testing should encompass the environment,

network, and key applications. The goal of testing is to determine if unauthorized access to key systems

and files can be achieved. If access is achieved, the vulnerability should be corrected and the

penetration testing re-performed until the test no longer allows unauthorized access or other malicious

activity.

18 | P a g e

Risk Assessment

Risk analysis serves two main purposes in testing: it forms the basis for risk-based testing, discussed

below, and it also forms the basis for test prioritization. The need for test prioritization arises because

there is rarely enough time to test as thoroughly as the tester would like, so tests have to be prioritized

with the expectation that tests with lower priority may not be executed at all. Risk analysis can be used

to rank test activities, giving priority to tests that address the more important risks.

Risk-Based Testing

As stated above, risk based testing uses risk to prioritize and emphasize the appropriate tests during

test execution. In simple terms, risk is the probability of occurrence of an undesirable outcome. This

outcome is also associated with an impact. Since there might not be sufficient time to test all

functionality, Risk based testing involves testing the functionality which has the highest impact and

probability of failure.

Fuzz Testing

Similar to penetration testing, Fuzz testing is used to discover coding errors and security loopholes in

software, operating systems or networks. It is accomplished by inputting invalid, unexpected, or random

data, called fuzz, to the system. It is then monitored for exceptions such as crashes, or failing built-in

code assertions or for finding potential memory leaks.

Source Code/Static Analysis

This is the analysis of computer software source code, performed without executing the program.

Static Analysis is typically performed during code review. An automated tool is used to look at the unit,

technology, and system levels of code. Some tools are starting to move into the Integrated

Development Environment (IDE), allowing detection during the software development phase itself. This

provides immediate feedback to the developer on issues they might be introducing into the code

during code development. This immediate feedback is very useful as compared to finding vulnerabilities

much later in the development cycle.

Injection Testing

The most common injection attacks include SQL injection, XPATH, HTML, and JavaScript (XSS

or cross site scripting). The first step in identifying injection flaws is to understand where user

input is captured and used by the application, understanding the flow of data. Understanding

which technologies are used in the application, allows an accurate sense of the scope of the

19 | P a g e

project and what technologies and attacks you need to probe. Each type of possible injection

attacks will require its own set of tests.

Security Testing Approach

The first step is to understand the business requirement, security goals and objective in terms of

security compliance of the organization.

Understand and analyze the requirements of the application under test.

Collect all system setup information used for development of software and network like

operating systems, technology, and hardware.

Make out the list of vulnerabilities and security risks.

Based on above step prepare threat profile.

Based on identified threat, vulnerabilities and security risks prepare test plan to address these

issues.

For each identified threat, vulnerabilities and security risks prepare traceability matrix.

Identify the tool to execute the all security test cases.

Create the security test case suites.

Run the security test cases and retest the defect fixes.

Execute the regression test cases.

Prepare detailed report of security testing which contains vulnerabilities and threats contained,

detailing risks, and still open issues etc.

20 | P a g e

Security Testing Tools

Microsoft Baseline Security Analyzer – “provides a streamlined method to identify missing security

updates and common security misconfigurations.” (Microsoft, 2015) This is a scan tool which can

perform local or remote scans of Microsoft Windows systems.

21 | P a g e

Works Cited

amicon. (2010). xss - cross-site scripting. Retrieved September 2015, from amicon:

http://www.amicontech.com/blog/xss-cross-site-scripting-in-ofbiz-opentaps/

Code Project. (2015, March 11). Insecure Direct Object Reference. Retrieved September 2015, from Code

Project: http://www.codeproject.com/Articles/885301/be-secure-from-insecure-direct-object-

reference

Hack This . (2015). Cross Site Request Forgery. Retrieved September 2015, from Hack This:

https://www.hackthis.co.uk/articles/cross-site-request-forgery

Microsoft. (2015). Microsoft Baseline Security Analyzer 2.3 (for IT Professionals). Retrieved September 11,

2015, from Microsoft: http://www.microsoft.com/en-us/download/details.aspx?id=7558

OWASP. (2013). Top 10 2013. Retrieved September 2015, from OWASP:

https://www.owasp.org/index.php/Top_10_2013-Top_10

Software Testing Fundamentals. (2013, March 3). Security Testing. Retrieved September 2015, from

Software Testing Fundamentals: http://softwaretestingfundamentals.com/security-testing/

Software Testing Help. (2015, Une 26). An approach for Security Testing of Web Applications. Retrieved

September 2015, from Software Testing Help: http://www.softwaretestinghelp.com/security-

testing-of-web-applications/

Veracode. (2015). AppSec (Application Security) Knowledge Base. Retrieved September 2015, from

Veracode: http://www.codeproject.com/Articles/885301/be-secure-from-insecure-direct-object-

reference

Veracode. (2015). Veracode SQL Injection Cheat Sheet & Tutorial. Retrieved September 6, 2015, from

Veracode: http://www.veracode.com/security/sql-injection

Wikipedia. (2015, September 8). Security Testing. Retrieved September 2015, from Wikipedia:

https://en.wikipedia.org/wiki/