Security Testing and Penetration Testing Notes

Security Testing and Penetration Testing

Learning Outcome

• Demonstrate how to perform security testing and penetration testing (static, dynamic, and fuzz testing) on an application.

Lecture Outline

1. Overview of Security Testing
2. Penetration Testing
3. Fuzz Testing
4. Static and Dynamic Analysis
5. Integrating Security Testing into CI/CD Pipelines
6. Comparison: Testing Type
7. Real-World Examples with Different Security Testing Types
8. Summary

Overview of Security Testing

What is Security Testing?

• A process to identify vulnerabilities and weaknesses in software systems.
• Objective: Ensure that software protects data and maintains functionality as intended.

Why is it Important?

• Prevents data breaches
• Protects user trust
• Ensures regulatory compliance (e.g., GDPR, HIPAA)

Types of Security Testing

Penetration Testing

Definition

• Simulates attacks to exploit vulnerabilities in a system, like an ethical hacker.

Phases of Penetration Testing

• Planning & Reconnaissance
• Scanning (Port scan, service enumeration)
• Gaining Access (SQLi, XSS)
• Maintaining Access
• Analysis & Reporting

Case Study: Target Corporation (2013 Breach)

• Attackers exploited a third-party vendor access.
• Penetration testing could’ve identified insecure external access policies.

Types of Penetration Testing

Advantages and Disadvantages

Fuzz Testing

Definition

• Sends malformed or random data as input to discover vulnerabilities.

How It Works

1. Input data is generated (random or based on templates)
2. Application response is monitored for crashes, memory leaks, or exceptions.

Example

• Testing a file parser by feeding it corrupted image files.

Case Study - Apple iMessage (2016)

• Fuzzing found a vulnerability that allowed remote code execution.

Best Used For

• Protocol parsers
• Media files (e.g., image viewers)
• Network services

Advantages and Disadvantages

Static and Dynamic Analysis

Static Analysis (SAST)

• Analyzing source code without executing the program

Definition

• Static Code Analysis involves examining source code or binaries before the software is run to identify potential vulnerabilities, logic flaws, and coding standard violations.

Common Techniques

• Pattern Matching & Rules: Detects known insecure functions (e.g., strcpy, eval)
• Data Flow Analysis: Tracks how data moves through code to spot tainted data flows
• Control Flow Analysis: Checks logical code paths for unreachable or insecure code
• Code Metrics: Flags overly complex or lengthy functions (linked to bugs or risks)

Examples of What It Can Detect

• SQL Injection flaws in code
• Cross-Site Scripting (XSS) in web templates
• Hardcoded credentials (e.g., API keys, passwords)
• Buffer overflows (unsafe memory handling in C/C++)

Popular Tools

• SonarQube, Fortify, Checkmarx, Bandit (for Python)

Advantages

• Fast feedback during development
• Catches issues early (shift left)
• No need for a running application

Disadvantages

• May report false positives
• Can't detect runtime-specific issues
• Needs access to source code

Dynamic Analysis (DAST)

• Testing application behavior during execution

Definition

• Dynamic Code Analysis involves running the application and monitoring its runtime behavior to detect security issues like memory leaks, logic errors, or unauthorized access.

Common Techniques

• Fuzz Testing: Sending malformed/random inputs to observe crashes
• Instrumentation: Injecting tracking logic to monitor behavior
• Dynamic Taint Analysis: Observing how input data flows at runtime
• Memory Analysis: Detects leaks or access violations

Examples of What It Can Detect

• Authentication bypasses
• Race conditions
• Memory leaks and buffer overflows (at runtime)
• Session hijacking or insecure cookie handling

Popular Tools

• OWASP ZAP (web applications), Burp Suite Pro (DAST), Valgrind (memory debugging for C/C++), AppScan

Advantages

• Catches real-world vulnerabilities
• Detects issues missed by static analysis
• Can be applied to third-party/closed-source apps

Disadvantages

• Slower than static analysis
• Needs a working environment and test data
• Limited code coverage compared to static analysis

Quick Comparison: Static Analysis (SAST) vs. Dynamic Analysis (DAST)

SAST vs DAST vs Penetration Testing

• SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing) vs penetration testing types (white-box, black-box, grey-box).

Analogy: Testing a Safe Activity

How Penetration Testing Types Compare

Summary

• SAST ≈ White-box testing because it requires source code access.
• DAST ≈ Black-box testing because it tests the app without knowing its internals.
• Penetration Testing is broader and more goal-oriented:
  • White-box pen testing uses insider knowledge.
  • Black-box pen testing simulates an outsider with no knowledge.
  • Grey-box is in-between.
• Key Difference: SAST / DAST are security testing methods/tools, while penetration testing is a security assessment approach (often including human expertise, strategy, and tools).

Integrating Security Testing into CI / CD Pipelines

• CI: Continuous Integration
• CD: Continuous Delivery (or Deployment).

What is CI/CD Pipelines?

• CI/CD stands for Continuous Integration and Continuous Delivery (or Deployment).
• It's a modern DevOps practice that automates the process of building, testing, and deploying software, making development faster, safer, and more reliable.
• CI: Continuous Integration
• CD: Continuous Delivery / Deployment
• Developers frequently push code (commits) into a shared repository (e.g., GitHub, GitLab).
• Each commit triggers:
  • Automated build
  • Automated tests (unit, security, etc.)
  • Code quality checks (e.g., static analysis)
• Once code passes CI, CD automates the release process to move the tested software to:
  • Staging (for manual approval)
  • or Production (if fully automated)
• 💡💡 Goal: Catch bugs or issues early before code is merged into production.
• 💡💡 Goal: Deliver features, fixes, and updates quickly and reliably.

Why Integration Matters

• Early detection = lower remediation cost
• Automated = consistent and repeatable testing

Integrating Security Testing into CI/CD Pipelines

• Also known as "Shift-Left Security" or DevSecOps, this means embedding security testing early and throughout the pipeline—not just before release.

Example CI/CD Pipeline with Security

• Developer commits code → triggers CI
• Static analysis runs to find code issues
• Build is created
• Fuzz or unit tests run on build
• DAST tool scans staging app
• Security gate checks for vulnerability thresholds
• Deploy only if passed

Security Actions by Stage

Benefits of Security in CI/CD

• Early detection of security flaws
• Reduced cost of fixing vulnerabilities
• Automated enforcement of security best practices
• Promotes a security-first culture in DevOps

Challenges

• Balancing speed vs. security scans
• False positives if tools not configured properly
• Requires security awareness from developers

CI/CD Pipeline (with security) – Simple Flow Diagram

• [Developer Commit]
• ↓
• [CI] → Static Code Analysis (SAST)
• ↓
• [Build] → Dependency Scanning
• ↓
• [Test] → DAST, Fuzzing
• ↓
• [CD] → Secure Deployment to Staging/Production
• ↓
• [Monitor] → Runtime Threat Detection & Logging

Comparison: Testing Type

Comparison Table: Testing Type Purposes

Real-World Examples with Different Security Testing Types

Example 1: E-Commerce Web Application

Wrap-up Summary

Tutorial Activity: Real-World Examples with Different Security Testing Types

• Example 2: Online Banking Mobile App
• Example 3: Hospital Management System (Web-Based)
• Example 4: University Student Portal
• Example 5: Smart IoT Device Web Interface