Transcript
Page 1: Security Testing for Testing Professionals

 

 

 

rial  

 

Presented by: 

Jeff Payne C  

Brought to you by: 

  

340 Corporate Way, Suite   Orange Park, FL 32073 888‐2

MF AM Tuto4/7/2014 8:30 AM     

“Security Testing for Testing Professionals”  

 

overos, Inc     

    

300,68‐8770 ∙ 904‐278‐0524 ∙ [email protected] ∙ www.sqe.com 

 

Page 2: Security Testing for Testing Professionals

       

              

Jeff Payne is CEO and founder of Coveros, Inc., a software company that builds eros

y s

     

Jeff Payne Coveros, Inc.

 

secure software applications using agile methods. Since its inception in 2008, Covhas become a market leader in secure agile principles and has been recognized by Inc. magazine as one of the fastest growing private US companies. Prior to founding Coveros, Jeff was chairman of the board, CEO, and cofounder of Cigital, Inc., a market leader in software security consulting. Jeff has published more than thirtpapers on software development and testing, and testified before Congress on issueof national importance, including intellectual property rights, cyber terrorism, and software quality.

Page 3: Security Testing for Testing Professionals

1 © Copyright 2013 Coveros Corporation. All rights reserved.

Security Testing

for Test Professional

Page 4: Security Testing for Testing Professionals

2 © Copyright 2013 Coveros, Inc.. All rights reserved.

Coveros helps organizations accelerate the delivery of secure, reliable software

Our consulting services: – Agile software development

– Application security

– Software quality assurance

– Software process improvement

Our key markets: – Financial services

– Healthcare

– Defense

– Critical Infrastructure

Areas of Expertise

About Coveros

Page 5: Security Testing for Testing Professionals

3 © Copyright 2013 Coveros, Inc.. All rights reserved.

Agenda

Introduction to Security Testing – Information security – Software security – Risk assessment – Security testing

Security Requirements & Planning – Functional security requirements – Non-functional security requirements – Test planning

Testing for Common Attacks

Integrating Security Testing into the Software Process

Page 6: Security Testing for Testing Professionals

4 © Copyright 2013 Coveros, Inc.. All rights reserved.

Trainer

Jeffery Payne [email protected]

Jeffery Payne is CEO and founder of Coveros, Inc., a software company that

helps organizations accelerate the delivery of secure, reliable software. Coveros

uses agile development methods and a proven software assurance framework to

build security and quality into software from the ground up. Prior to founding

Coveros, Jeffery was Chairman of the Board, CEO, and co-founder of Cigital, Inc.

Under his direction, Cigital became a leader in software security and software

quality solutions, helping clients mitigate the risk of software failure. Jeffery is a

recognized software expert and popular speaker at both business and technology

conferences on a variety of software quality, security, and agile development

topics. He has also testified before Congress on issues of national importance,

including intellectual property rights, cyber-terrorism, Software research funding,

and software quality.

Page 7: Security Testing for Testing Professionals

5 © Copyright 2013 Coveros, Inc.. All rights reserved.

Introduction to Security Testing

Page 8: Security Testing for Testing Professionals

6 © Copyright 2013 Coveros, Inc.. All rights reserved.

When you hear the term “Information Security” or

“Security Testing” …

What do you think it means?

What comes to mind?

What is Information Security?

Page 9: Security Testing for Testing Professionals

7 © Copyright 2013 Coveros, Inc.. All rights reserved.

Definition of Information Security

Information Security means protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, perusal, inspection, recording or destruction.

The key concepts of Information Security include: – Confidentiality

– Integrity

– Availability

– Authenticity

– Non-Repudiation

What is Information Security?

Page 10: Security Testing for Testing Professionals

8 © Copyright 2013 Coveros, Inc.. All rights reserved.

The Software Security Problem

Our IT systems are not castles any longer!

Page 11: Security Testing for Testing Professionals

9 © Copyright 2013 Coveros, Inc.. All rights reserved.

Why Software Security is Important

Page 12: Security Testing for Testing Professionals

10 © Copyright 2013 Coveros, Inc.. All rights reserved.

How to Define Security Risk in Software

Understanding Risk

Common Security Nomenclature – Risk: a possible future event which, if it occurs, will lead to an

undesirable outcome

– Threat: A potential cause of an undesirable outcome

– Asset: Data, application, network, physical location, etc. that a threat may wish to access, steal, destroy, or deny others access to

– Vulnerability: Any weakness, administrative process, or act of physical exposure that makes an information asset susceptible to exploit by a threat.

– An exploit is a piece of software, a chunk of data, or sequence of commands that takes advantage of a vulnerability in order to cause unintended or unanticipated behavior to occur on computer software, hardware, or something electronic.

– Attack: the approach taken by a threat to exploit a vulnerability Denial of service, spoofing, tampering, escalation of privilege

Page 13: Security Testing for Testing Professionals

11 © Copyright 2013 Coveros, Inc.. All rights reserved.

Risk Assessment

A risk assessment is commonly carried out by a team of people who have subject area knowledge of the business and product. Members of the team provide a qualitative analysis based on informed opinion of threats that will later be used in a more quantitative analysis.

The team should also define what is an acceptable amount of risk that the organization can assume. We assume we can’t identify all risks nor eliminate them; this is often referred to as residual risk.

Understanding Risk

Page 14: Security Testing for Testing Professionals

12 © Copyright 2013 Coveros, Inc.. All rights reserved.

Risk Assessment

Break into teams of 2-3 people.

Each team will identify potential threats to a software application described on the next slide.

– Who would want to compromise this application?

– What assets would they be after if they did?

Once each threat is identified, provide impact and likelihood ratings (High, Medium, Low) for each threat.

– Justify your answers

Exercise Time Limit: 15 Minutes

Exercise

Page 15: Security Testing for Testing Professionals

13 © Copyright 2013 Coveros, Inc.. All rights reserved.

Your company, SecureTelco, has developed an instant messaging program to be used for private use in customers homes and for companies and government agencies.

SecureChat requires users to sign up with an account prior to using the system. After authenticating with a username and password, each user can message other users and expect their conversations to be private.

Users have the ability to add/remove friends from their contact list, search for friends based on their email, block users from IMing them, become “invisible” to all users on demand.

Messages archives and activities logs document user behavior and can be retrieved by the user or a SecreTelco Administrator through the application or by the administrative console, respectively.

Risk Assessment

Exercise

Page 16: Security Testing for Testing Professionals

14 © Copyright 2013 Coveros, Inc.. All rights reserved.

Risk Assessment Questions

Business / Mission Motivation

– What is the importance/criticality of the system?

– What assets exist in the system?

– What is the impact if C, I, A principles violated?

User Capabilities and Exposure

– How is access different for user roles?

– What operations can each performed by different users?

Threat Motivation

– Why might someone attack the system?

– Who might want to attack? (insiders, outsiders)

– What might attackers accomplish?

– What’s the cost of failure?

Exercise

Page 17: Security Testing for Testing Professionals

15 © Copyright 2013 Coveros, Inc.. All rights reserved.

Threats to system Assets of interest

Exercise Results

Page 18: Security Testing for Testing Professionals

16 © Copyright 2013 Coveros, Inc.. All rights reserved.

What? How?

Security Testing is testing used to determine whether an information system protects its data from its threats.

Security Testing is not a silver bullet for your enterprise

security. Security Testing doesn’t fix your security, it only

makes you aware of it. Security must be built into your

software

A sound Security Testing process performs testing activities:

– Before development begins

– During requirements definition and software design

– During implementation

– During deployment

– During maintenance and operations

Security Testing

Page 19: Security Testing for Testing Professionals

17 © Copyright 2013 Coveros, Inc.. All rights reserved.

Provides a level of confidence that your system performs securely within specifications.

Security Testing is a preventative way to find small issues before they become big, expensive ones.

– The 2007 CSI Computer Crime and Security Survey performed an analysis of the average cost of a web security breach. The average loss reported in the survey was $350,424.

Security Testing ensures that people in your organization understand and obey security policies.

If involved right from the first phase of system development life cycle, security testing can help eliminate flaws in the design and implementation of the system.

Why is it important?

Security Testing

Page 20: Security Testing for Testing Professionals

18 © Copyright 2013 Coveros, Inc.. All rights reserved.

Major goals of security testing

– Test the security features of a system

– Test the security properties of a system

– Test whether the system is implemented in a secure fashion

Security features are controls you’ve implemented to protect your system

– Authentication, Authorization, Encryption, etc.

Security properties are closely associated with non-functional security requirements

Secure implementation means the software does not have embedded vulnerabilities due to poor design or coding practices

Aspects of Security Testing

Security Testing

Page 21: Security Testing for Testing Professionals

19 © Copyright 2013 Coveros, Inc.. All rights reserved.

Testing security features/controls is most akin to normal

functional testing

– Functional security requirements drive this testing

– Integration of security features into overall application

Testing security properties requires tests that cross many

features of the system

– Develop tests based on non-functional security requirements and

identified risks / threats

– Tests that assure the implementation does not include known flaws

and vulnerabilities

Testing Aspects of Security

Security Testing

Page 22: Security Testing for Testing Professionals

20 © Copyright 2013 Coveros, Inc.. All rights reserved.

Security Requirements

Page 23: Security Testing for Testing Professionals

21 © Copyright 2013 Coveros, Inc.. All rights reserved.

What are Security Requirements?

What is a Security Requirement?

Security Requirements describe functional and non-

functional requirements that need to be satisfied in order to

achieve the security attributes of an IT system or

application.

What does that mean?

Functional Security Requirements

Additions to functional requirements that define what the software should not do.

Requirements that define security controls

Non-Functional Security Requirements

Additional non-functional requirements that define what overall security the system must provide

Page 24: Security Testing for Testing Professionals

22 © Copyright 2013 Coveros, Inc.. All rights reserved.

Functional Requirements

Your Standard Definition

Functional Requirements: These are statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. In some cases, the functional requirements may also have explicitly state what the system should not do.

Where does the Security fit in?

Security features should already have functional requirements associated with them

Don’t assume they are good or adequately address what the software should not do

Misuse and abuse cases should be defined to understand risks that a threat may utilize to attack the system

Make sure you check all features for misuse cases

Page 25: Security Testing for Testing Professionals

23 © Copyright 2013 Coveros, Inc.. All rights reserved.

Part of your security requirements involve security features,

or security controls, that help protect your system

They define the way your system will behave with respect to

other security properties and non-functional requirements

Examples:

– Authentication and Identity Management

– Authorization and Access Control

– Input Validation & Encoding

– Encryption

– Error and Exception Handling

– Auditing and Logging

Security Features (aka Security Controls)

Functional Security Requirements

Page 26: Security Testing for Testing Professionals

24 © Copyright 2013 Coveros, Inc.. All rights reserved.

Use cases describe functionality of how someone might use

a system

Misuse cases describe how someone might (perhaps

unintentionally) do something in the system with a negative

security impact

Abuse cases describe how a malicious attacker might

deliberately misuse your system to his advantage

We use misuse and abuse cases to understand what our

system must protect against and help design security tests

Misuse and Abuse Cases

Functional Security Requirements

Page 27: Security Testing for Testing Professionals

25 © Copyright 2013 Coveros, Inc.. All rights reserved.

Functional Security Requirements

Break into teams of 2-3 people.

Each team will identify potential misuse cases with the

following security requirements, if any exist.

If a misuse case is identified, write a replacement or

additional functional requirement(s).

– It would be best to make sure no misuse cases can be derived from

your new requirement(s).

Exercise Time Limit: 15 Minutes

Exercise

Page 28: Security Testing for Testing Professionals

26 © Copyright 2013 Coveros, Inc.. All rights reserved.

SecureChat Authentication Requirements

– When a user attempts to authenticate with a valid username and an invalid password, the application shall not authenticate the user and return them to the authentication page.

– The system must alert the user that their attempt to authenticate has failed due to an incorrect password (“Invalid Password”) utilizing the standard error text formatting.

– When a user attempts to authenticate with a invalid username, the application shall not authenticate the user and return them to the authentication page.

– The system must alert the user that their attempt to authenticate has failed due to an incorrect username (“Invalid Username”) utilizing the standard error text formatting.

– What a user attempts to authenticate using a username and a valid password, the application shall authenticate the user and redirect them to the homepage.

Functional Security Requirement Examples

Exercise

Page 29: Security Testing for Testing Professionals

27 © Copyright 2013 Coveros, Inc.. All rights reserved.

Authentication Use Case (as requirements are written)

Exercise

Enter username

and password

User

authentication

Show invalid

ID error msg

Show invalid

password msg

SecureChat

User

SecureChat

Server

Page 30: Security Testing for Testing Professionals

28 © Copyright 2013 Coveros, Inc.. All rights reserved.

Authentication Use/Misuse Case Artifact

Exercise

Enter username

and password

User

authentication SecureChat

User

SecureChat

Server

Threat

Threatens

Mitigates

Se

cu

rity c

on

trols

Attacks

Page 31: Security Testing for Testing Professionals

29 © Copyright 2013 Coveros, Inc.. All rights reserved.

Non-Functional Requirements

Your Standard Definition

Non-Functional Requirements: These are constraints on the services or functions offered by the system.

Availability, Reliability, Performance, Scalability, Testability, Security

Where does Security fit in?

Security is one of the cross-cutting concerns that must be addressed during testing

Threat modeling, architectural analysis, and code analysis are often used to enumerate risks and drive non-functional security testing

Tools can assist testing professionals with these efforts

Conformance with standards and regulations

Page 32: Security Testing for Testing Professionals

30 © Copyright 2013 Coveros, Inc.. All rights reserved.

Non-Functional Requirements

Example Non-functional Security Requirements

Confidential data will not be accessible by users other than through the SecureChat client

SecureChat shall have an availability of 99.9% at all times

All communication with the Securechat central server must be encrypted using 128-bit encryption

SecureChat shall process a minimum of 8 transactions per second.

All SecureChat code shall be reviewed against our internal coding standards prior to release

Page 33: Security Testing for Testing Professionals

31 © Copyright 2013 Coveros, Inc.. All rights reserved.

Security Test Planning

Functional security tests based upon the functional security requirements should be planned, designed, and executed along with the rest of the functional testing

– Typically covered by a combination of unit, feature, and integration testing activities

– Don’t forget integration … COTS security features are often integrated incorrectly

Non-functional security tests should be planned, designed, and executed as followed:

– Unit level: secure code scanning to identify vulnerabilities

– Feature level: web application security testing plus any specific non-functional security requirements that can be performed at this level

– Integration/System levels: more of the above based upon threats & risks

– System level: end-to-end testing and penetration testing that must be done a production-like environment

What goes where

Page 34: Security Testing for Testing Professionals

32 © Copyright 2013 Coveros, Inc.. All rights reserved.

Testing to Mitigate Common Attacks

Page 35: Security Testing for Testing Professionals

33 © Copyright 2013 Coveros, Inc.. All rights reserved.

Input Validation

Most common application security weakness: failure to properly validate input

– From client

– From environment (often overlooked)

Leads to many of the major vulnerabilities found in applications

– Interpreter injection (SQL, JavaScript, XML, Command, …)

– Locale/Unicode attacks

– File system attacks

– Buffer overflows

Data from a client application or a user should never be trusted as they are susceptible to injection attacks

Common Attacks

Page 36: Security Testing for Testing Professionals

34 © Copyright 2013 Coveros, Inc.. All rights reserved.

Injection attacks result when input from a user is interpreted

by a command processor or formed to manipulate the

program stack/heap

– These are, by far, the most rampant category of attacks over the past

20 years

What are Injection Attacks?

Common Attacks

<body><p>

<?

$msg = “Hi, “ + $name + “.”;

echo $msg

?>

</p></body>

<body><p>

Hi, Joe.

</p></body>

$name = Joe

<body><p>

Hi,

<script src=“http://www.bad.com/attack.js”/>.

</p></body>

$name = <script src=“http://bad.com/attack.js”/>

Page 37: Security Testing for Testing Professionals

35 © Copyright 2013 Coveros, Inc.. All rights reserved.

Input characters that aren’t expected

– More input than expected

– Different input than expected

– Executable input that is unexected

Input encoded strings

– Automatically converted/decoded by browsers and other

frameworks

These “mistakes” are what attackers leverage to trigger input

vulnerabilities in our systems

Common Input Mistakes

Common Attacks

Page 38: Security Testing for Testing Professionals

36 © Copyright 2013 Coveros, Inc.. All rights reserved.

Types of Input Validation

Integrity Checks – Ensure that the data has not been tampered with and is the same as before.

– Integrity checks must be included wherever data passes from a trusted to a less trusted boundary, such as from the application to the user's browser in a hidden field, or to a third party payment gateway, such as a transaction ID used internally upon return.

– The type of integrity control (checksum, HMAC, encryption, digital signature) should be directly related to the risk of the data transiting the trust boundary.

Validation - Ensure that the data is strongly typed, correctly syntaxed, within length boundaries, contains only permitted characters or that numbers are correctly signed and within boundary ranges.

– Validation must be performed on every tier. For example, the presentation layer should validate web related issues, persistence layers should validate for persistence issues, etc.

Common Attacks

Page 39: Security Testing for Testing Professionals

37 © Copyright 2013 Coveros, Inc.. All rights reserved.

Input Validation Approaches

Accept Known Good

– Check the data is one of a set of tightly constrained known good values

– “Whitelist” validation

– Only works when set of good values is small or previously identified

Reject Known Bad

– Reject strings that contain potentially unacceptable characters (ex. If you’re not expecting JavaScript, reject %3f)

– “Blacklist” validation

– A dangerous strategy because the possible set of bad data is infinite; causes constant maintenance of blacklist

Sanitize

– Rather than accept or reject, change the input into an acceptable format

– Sound software engineering practice

Validating Input

Page 40: Security Testing for Testing Professionals

38 © Copyright 2013 Coveros, Inc.. All rights reserved.

A very common vulnerability

Allows an attacker to inject script into a vulnerable web

system that attacks the user

Example:

Cross-Site Scripting

Common Input Attack #1

Type your name: Joe

http://myweb.com/index.php

Hi, Joe!

http://myweb.com/index.php?name=Joe

What happens if we type our name as:

<script>alert(“Joe Hacker!”)</script>

Page 41: Security Testing for Testing Professionals

39 © Copyright 2013 Coveros, Inc.. All rights reserved.

Reflected Cross-Site Scripting

Testing for Reflected Cross-Site Scripting

– Reflected Cross Site Scripting (XSS) is another name for non-persistent XSS, where the attack doesn’t load with the vulnerable web application but is originated by the victim loading the offending URI using the victim’s credentials. Commonly, an attacker creates and tests an offending URI, in which the victim

loads the URI on their browser.

Attackers typically leverage these vulnerabilities to install key loggers, steal victim cookies, perform clipboard theft and change the content of the page

– Testing Process Detect Input Vectors

Analyze Each input vector to detect potential vulnerabilities. Input data is typically harmless, but triggers web browser responses.

Report on Findings

Analyze report and attempt to exploit with an attack that has a realistic impact on web application security.

Cross Site Scripting

Page 42: Security Testing for Testing Professionals

40 © Copyright 2013 Coveros, Inc.. All rights reserved.

Stored Cross-Site Scripting

Testing for Stored Cross-Site Scripting

– Stored XSS is the most dangerous type. Web applications that allow users to store data are potentially exposed to this type of attack. This occurs when a web application gathers malicious input and stores,

unfiltered, that input in a data store for later use. As a consequence the malicious data will appear to be part of the web site and run on the user’s browser.

The more privileges the end user has the more dangerous this attack is.

– Testing Process Identify input forms

Analyze HTML Code

Test for Stored XSS

Report on Findings

Analyze report and attempt to exploit with an attack that has a realistic impact on web application security.

Cross Site Scripting

Page 43: Security Testing for Testing Professionals

41 © Copyright 2013 Coveros, Inc.. All rights reserved.

Cross Site Scripting Patterns (cont.)

Testing for DOM-Based Cross Site Scripting

– DOM-based XSS is the name for bugs which are the result of active

content on a page, typically obtaining user input and doing

something unsafe with it to lead to a XSS bug.

In comparison to other cross site scripting vulnerabilities (reflected and stored

XSS), where an unsanitized parameter is passed by the server, returned to the

user and executed in the context of the user’s browser, a DOM based cross site

scripting vulnerability controls the flow of the code by using elements of the

Document Object Model (DOM) along with code crafted by the attacker to

change the flow.

– Manual testing is almost always required for this type of XSS attack

and requires knowledge of the code, especially around any use of

JavaScript.

Cross Site Scripting

Page 44: Security Testing for Testing Professionals

42 © Copyright 2013 Coveros, Inc.. All rights reserved.

Cross Site Scripting Patterns (cont.)

Testing for Cross Site Flashing

– ActionScript is the language used by Flash applications when

dealing with interactive needs due to some poor implementation

patterns.

New versions of Flash player are often released to mitigate some attacks, but

poor programming practices often still result in exploits.

– Manual testing is almost always required for this type of XSS attack

and requires knowledge of the code, especially around any use of

ActionScript.

Cross Site Scripting

Page 45: Security Testing for Testing Professionals

43 © Copyright 2013 Coveros, Inc.. All rights reserved.

SQL Injection

What is SQL Injection? – An SQL injection attack consists of the insertion or “injection” of an

SQL query via input data from the client to the application. A successful exploit could read sensitive data, modify data, execute administrative operations, recover the content to a given file and, in some cases, issue commands to the operating system.

Types of SQL Injection – Inband – Data is extracted using the same channel that is used to

inject SQL code. In the simplest form, the retrieved data is presented directly to the application web page.

– Out-of-band – Data is retrieved using a different channel (e.g., an email with the results of the query is generated and sent to the tester).

– Inferential – Data is not transferred, but the tester is able to reconstruct the information by sending particular requests and observing the resulting behavior of the DB Server.

Common Input Attack #2

Page 46: Security Testing for Testing Professionals

44 © Copyright 2013 Coveros, Inc.. All rights reserved.

SQL Injection Example

Consider the following SQL query:

– SELECT * FROM Users WHERE Username='$username' AND

Password='$password'

Assume the values of the input fields are obtained from the

user through a web form. Suppose we insert the following

Username and Password values:

– $username = 1' or '1' = '1

– $password = 1' or '1' = '1

The query will be:

– SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND

Password='1' OR '1' = '1'

Common Attack #2: SQL Injection

Page 47: Security Testing for Testing Professionals

45 © Copyright 2013 Coveros, Inc.. All rights reserved.

SQL Injection Example (cont.)

Another test involves the use of the UNION operator. We suppose for our examples that the query executed from the server is the following:

– SELECT Name, Phone, Address FROM Users WHERE Id=$id

We will set the following Id value: – $id = 1 UNION ALL SELECT creditCardNumber,1,1 FROM

CreditCardTable NOTE: we have selected other two values. These two values are necessary, in order

to avoid a syntax error.

We will have the following query: – SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION

ALL SELECT creditCardNumber,1,1 FROM CreditCardTable

The keyword ALL can be used to get around the DISTINCT keyword.

SQL Injection

Page 48: Security Testing for Testing Professionals

46 © Copyright 2013 Coveros, Inc.. All rights reserved.

Testing for SQL Injection (cont.)

Where to look for SQL Injection – Authentication forms: Chances are high that the user credentials

are checked against a database that contains all usernames and passwords (or their password hashes)

– Search Engines: Strings submitted could be used in a query that extracts relevant records from a database.

– E-Commerce Sites: Products and their characteristics are very likely to be stored in a database.

– Use your inherent knowledge of your application to pinpoint your testing efforts.

SQL Injection

Page 49: Security Testing for Testing Professionals

47 © Copyright 2013 Coveros, Inc.. All rights reserved.

Testing for all cases of injection attacks can be laborious

There are lots of tools out there to help

Leverage tools but also make sure validation code is correct

Understand architecture to test unique components that

include scripting / executable capabilities

Use Tools!

Common Attacks

Page 50: Security Testing for Testing Professionals

48 © Copyright 2013 Coveros, Inc.. All rights reserved.

Integrating Security into Your Testing

Process

Page 51: Security Testing for Testing Professionals

49 © Copyright 2013 Coveros, Inc.. All rights reserved.

How do you add Security in?

Software Development Life Cycle

Define Use/Abuse cases

Security requirements

Assess threats and

assets

Design Threat modeling

Security test planning

Develop

Deploy

Static Analysis

Risk-based security testing

Penetration testing

Page 52: Security Testing for Testing Professionals

50 © Copyright 2013 Coveros, Inc.. All rights reserved.

Classes of Tools

Risk-based security testing tools – Proactive web app scanners – Proxies – Fuzzers

Secure code scanning tools

Threat modeling (planning tool)

Network scanning tools

Password Crackers

Tools to Support Security Testing

Page 53: Security Testing for Testing Professionals

51 © Copyright 2013 Coveros, Inc.. All rights reserved.

Web Application Scanners and Proxies

Where to use? – Looking for XSS, Injection and input validation vulnerabilities; some

tools will attempt to actively exploit vulnerabilities.

Free Tools – Zed Attack Proxy – Nikto – W3af – Paros – Skipfish – Wapiti – wfuzz

Paid Tools – Netsparker – WebSecurify – Big Commercial: IBM AppScan, Cenzic Hailstorm, HP WebInspect

Tools to Support Security Testing

Page 54: Security Testing for Testing Professionals

52 © Copyright 2013 Coveros, Inc.. All rights reserved.

Password Crackers & Brute Force Tools

Where to use? – When you want to break the default credentials or test your

authentication mechanisms against common security tools.

Free Tools – THC Hydra

– Cain and Abel

– Wfuzz

Paid Tools – John the Ripper

Tools to Support Security Testing

Page 55: Security Testing for Testing Professionals

53 © Copyright 2013 Coveros, Inc.. All rights reserved.

Network Security Tools

Where to use? – Scanning for mis-configurations

– Testing for OS, application and network vulnerabilities

Free Tools – OpenVAS

Paid Tools – Nessus

– Core Impact

Tools to Support Security Testing

Page 56: Security Testing for Testing Professionals

54 © Copyright 2013 Coveros, Inc.. All rights reserved.

Wrap-Up

Page 57: Security Testing for Testing Professionals

55 © Copyright 2013 Coveros, Inc.. All rights reserved.

OWASP Foundation, “OWASP Testing Guide v3”,

https://www.owasp.org/index.php/OWASP_Testing_Project, 2008

Hope and Walther, “Web Security Testing Cookbook: Systematic Techniques to

Find Problems Fast,” O’Reilly, 2008

Whittaker and Thompson, “How to Break Software Security,” Addison-Wesley,

2003

Schneier, Bruce, “Secrets and Lies: Digital Security in a Networked World,”

Wiley, 2000

References

Page 58: Security Testing for Testing Professionals

56 © Copyright 2013 Coveros, Inc.. All rights reserved.

Questions?

Contact Information:

http://www.coveros.com

[email protected]

703.431.2920

Page 59: Security Testing for Testing Professionals

57 © Copyright 2013 Coveros, Inc.. All rights reserved.

Answers to Exercises*

* There are numerous possible answers to some exercises, these show one

possible answer

Page 60: Security Testing for Testing Professionals

58 © Copyright 2013 Coveros, Inc.. All rights reserved.

Formal Authentication Use/Misuse Case Artifact

Exercise

Enter username

and password

User

authentication

Show generic

error message

Lock account

after N failed

login attempts

Validate

password

minimum

length and

complexity

SecureChat

User

SecureChat

Server

Hacker

Brute Force

Attack

Guess User

Accounts

Dictionary

Attacks

Threatens

Mitigates

Mitigates

Mitigates

Mitigates


Top Related