Scribd
Upload
18 views21 pages

2.penetration Testing 2024

Uploaded by

smazzam2004
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
18 views21 pages

2.penetration Testing 2024

Uploaded by

smazzam2004
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 21

APPLICATION PENETRATION

TESTING

Dr. Hatem 2024


Overview

 What is penetration testing


 Why do penetration testing
 Examples of penetration tests
 Components of software security testing
 Conclusion
 Questions
What is Penetration Testing?

 Software testing that is specifically designed to


hunt down security vulnerabilities

 In computer software, a security vulnerability is


a software bug that can be used to violate
security.
Why Do Penetration Testing?

 Software can be correct without being secure


 Software can perform every specified action
flawlessly and still be exploited by a
malicious user
 Security bugs are typically hidden in nature

 Companies need to protect information and


business assets against hacking and data theft
Approaches for Penetration Testing

 Outsider with zero


knowledge
 Insider with limited
knowledge – valid
account with restrictive
privileges
 Insider with full
knowledge –
administrator account
Examples of Penetration Tests

 Parameter tampering
 Known vulnerabilities
 Brute force
 Session hijacking
 Information gathering
Creating a Security Testing Project

 Threat Models
 Test plan
 Test cases
 Problem reports
 Postmortem
*Threat Modeling

 A way of categorizing and analyzing the threats


to an application
 What information will a threat model help to
provide?
 Which assets need protection
 What threats is the application vulnerable to
 How important or how likely is each threat
 How can the threats be mitigated
STRIDE - Model of Threat Categories

 Spoofing identity - Illegal use of another person's


authentication information, such as a user name or
password.
 Tampering with data - malicious modification of data
 Repudiation - Users deny performing an action
 Information Disclosure - exposure of information to
unauthorized individuals
 Denial of Service - explicit attempt to prevent
legitimate users from using a service or system.
 Elevation of Privilege - an unprivileged user gains
privileged access
Partial Threat Tree
*Build a Test Plan

 Includes high level overview of test cases


 Identifies components to be tested
 States how exploratory testing will be done
 Test design and test execution at the same time
 Plan must also address
 Logistics
 Deliverables
 Test cases and tools
*Execute Test Cases

 Dependency testing
 User interface testing
 Design testing
 Implementation testing
Dependency Testing

 Dependency testing exposes insecurities related to


external resources
 File systems
 Registry
 External libraries
 Types of insecurities that can arise
 Denying the application access
 Tampering with and corrupting data
User Interface Testing

 Parameter tampering testing


 Changing the data within a parameter sent from one
Web page to another
 Command injection testing
 Manipulating input data sent to a Web server
 Buffer overflow testing
 Data sent as input to the server that overflows the
boundaries of the input area
Design Testing

 Helps to identify design errors


 Unsecured ports
 Default accounts
Implementation Testing

 TOCTOU – time-of-check-to-time-of-use
 A time gaps exists between when an application
checks security on a particular function or piece of
data and when that privilege is exercised
*The Problem Report

 Must include
 Reproduction steps
 List the steps that another tester/developer must
follow to reproduce the failure
 Severity
 What is the potential result of the failure
 Exploit scenarios
 The specific sequence of things an attacker can
do to take advantage of a security flaw and the
consequences of doing so
*Postmortems

 Includes a discussion by the testing team of


the bugs found
 Identifies improvements to the testing
process so that bugs are found sooner in
future security testing
 Performed after a project is complete
 Performed periodically for released products
when bugs are uncovered in the field
Conclusion

 Functional software testing is not enough


 Security testing must be included in the
software development process.
 Software quality and software security are
intertwined - you can't have one without the
other.
Questions

You might also like