View
106
Download
0
Category
Preview:
Citation preview
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/
Recommended