SECURITY TESTING

COMPLETE GUIDE

CIA Triad • VAPT • OWASP Top 10 • HTTP Security SSL/TLS • Authentication Testing • Google
Dorking

TOPICS COVERED IN THIS GUIDE

01 Introduction to Security Testing & CIA Triad

02 HTTP Methods & Parameter Security

03 VAPT & OWASP Top 10 Vulnerabilities

04 Security Recon Tools (Wappalyzer, Shodan, BuiltWith)

05 Authentication, Login & Session Security

06 SSL/TLS Configuration & Compliance

07 Google Dorking & OSINT Techniques

08 Interview Questions & Practice Tests

Security Training Program • Cybersecurity Division

CONFIDENTIAL — INTERNAL USE ONLY
CHAPTER 1

Introduction to Security Testing

Understanding the fundamentals: CIA Triad, Risk Management, and the Security Testing Process

1.1 What is Cybersecurity?

Cybersecurity is the practice of protecting computer systems, networks, programs, and data from digital attacks,
unauthorized access, damage, or theft. It encompasses a wide range of technologies, processes, and practices
designed to safeguard information systems and ensure the confidentiality, integrity, and availability of data.

In modern organizations, cybersecurity plays a critical role in:

• Protecting sensitive customer and organizational data from unauthorized access

• Ensuring business continuity by preventing system outages caused by attacks
• Maintaining regulatory compliance (GDPR, HIPAA, PCI-DSS, ISO 27001)
• Building trust with customers, partners, and stakeholders
• Preventing financial losses from cyber incidents and data breaches

1.2 The CIA Triad — Core Principles of Security

The CIA Triad is the foundational model of information security. Every security decision, policy, and control maps back
to one or more of these three pillars:

CIA Pillar Definition Controls & Examples

■ Confidentiality Ensures that information is accessible only to Encryption (AES-256), Access Control Lists,
authorized individuals. Data must be kept private Multi-Factor Authentication, Data masking,
and protected from unauthorized disclosure. Role-Based Access Control (RBAC)

■■ Integrity Ensures that information is accurate, complete, Digital signatures, Hash functions (SHA-256),
and has not been tampered with or modified by Checksums, Version control, Database
unauthorized parties during storage or transit. transaction logs, File integrity monitoring

■ Availability Ensures that authorized users can access Redundancy, Load balancing, Backups & DR
information and systems when needed. Systems plans, DDoS mitigation, Fault-tolerant
must remain operational and accessible. architecture, SLA monitoring

Real-World CIA Triad Violations

Incident Impact Triad Violation

Data breach at a hospital Patient records exposed online Confidentiality

Ransomware corrupts files Medical records encrypted/altered Integrity

DDoS on banking portal Users cannot access online banking Availability

Insider leaks salary data Employee pay exposed Confidentiality

SQL injection modifies DB Orders changed by attacker Integrity

1.3 The Security Testing Process

Security testing follows a structured lifecycle to systematically identify, assess, and remediate vulnerabilities. The four
main phases are:
Phase Description

Phase 1: Planning Define scope, objectives, and rules of engagement. Identify systems to test, testing
methodology (black/grey/white box), legal permissions, timelines, and team responsibilities.
Deliverable: Test Plan document.

Phase 2: Scanning Actively probe systems for weaknesses. Use automated scanners (Nessus, OpenVAS,
Burp Suite) and manual techniques to enumerate services, identify open ports, detect
outdated software, and map attack surface.

Phase 3: Exploitation Attempt to exploit found vulnerabilities to determine real-world impact. Use tools like
Metasploit, SQLMap, or manual exploit code. Document what was accessed, how far
lateral movement was possible.

Phase 4: Reporting Document all findings with clear severity ratings, evidence, and remediation steps.
Executive summary for management + technical details for developers. Include CVSS
scores, PoC screenshots, and fix recommendations.

1.4 Types of Security Testing

Test Type Description

VAPT Combines automated scanning and manual exploitation to find and validate security
weaknesses

SAST Analyzes source code without executing — finds bugs early in development (e.g.,
Checkmarx, SonarQube)

DAST Tests running applications by sending malicious inputs — simulates real attacks
(e.g., Burp Suite, OWASP ZAP)

IAST Combines SAST & DAST — uses agents inside running apps to monitor behavior
during testing

Red Team Testing Simulates a full adversarial attack — stealth, persistence, lateral movement, data
exfiltration

Blue Team / SOC Testing Tests defensive capabilities — detection time, incident response procedures, log
analysis

1.5 Cybersecurity Measures & Best Practices

Technical Controls
• Firewalls & IDS/IPS: Network firewalls filter traffic; Intrusion Detection/Prevention Systems monitor for anomalous
patterns
• Encryption: TLS 1.3 for data in transit; AES-256 for data at rest; end-to-end encryption for sensitive
communications
• Multi-Factor Authentication (MFA): Requires two or more verification factors — something you know, have, or are
• Patch Management: Regularly update OS, applications, and firmware to eliminate known CVE vulnerabilities
• Zero Trust Architecture: "Never trust, always verify" — every request must be authenticated regardless of network
location

Administrative Controls
• Security Awareness Training: Educate employees on phishing, social engineering, and secure password
practices
• Incident Response Plan: Documented procedures for detecting, containing, and recovering from security breaches
 • Access Control Policy: Principle of least privilege — users get only the minimum access needed for their role

1.6 Risk Management Framework

Risk management is the process of identifying, assessing, and mitigating security risks to an acceptable level.

RISK FORMULA

Risk = Threat × Vulnerability × Impact

Example:
Threat: Attacker targeting login page via brute force
Vulnerability: No rate limiting or account lockout mechanism
Impact: Full account takeover, data breach, reputational damage
Risk Level: HIGH — immediate remediation required

Severity Definition & SLA

CRITICAL Exploit publicly available; CVSS 9.0+; immediate patch required within 24–48 hours

HIGH Significant data or system compromise possible; CVSS 7.0–8.9; patch within 7 days

MEDIUM Limited impact; requires specific conditions; CVSS 4.0–6.9; patch within 30 days

LOW Minimal impact; difficult to exploit; CVSS 0.1–3.9; patch in next release cycle

INFORMATIONAL Best-practice improvement; no direct security impact; document and review

CHAPTER 2

HTTP Methods & Parameter Security

Understanding GET, POST, PUT, DELETE, PATCH and how improper handling creates vulnerabilities

2.1 HTTP Methods Overview

Method Description & Security Notes

GET Retrieve a resource. Should be idempotent and read-only. Parameters are in the URL (visible in logs,
browser history, Referer headers).

POST Submit data to create a resource. Parameters in request body. Not cached. Used for forms, file uploads,
API calls that modify state.

PUT Replace/update an entire resource. Idempotent — calling it multiple times has the same result. Requires
full resource representation.

DELETE Remove a resource. Idempotent. Must be properly authorized — missing auth checks allow mass deletion
attacks.

PATCH Partially update a resource. Sends only the changed fields. Non-idempotent by default. Often has weaker
validation than PUT.

OPTIONS Returns allowed HTTP methods for a URL. Can leak info about server capabilities if not properly
restricted.

HEAD Like GET but returns only headers, no body. Used to check resource existence without downloading
content.

2.2 Vulnerabilities from Improper HTTP Method Handling

GET Method — Security Issues

• Sensitive Data in URL: Passwords, tokens, or PII passed in GET parameters are logged in server logs, browser
history, and proxy logs
• CSRF via GET: If state-changing actions use GET, attackers can forge an HTML img tag pointing to
[Link]/transfer?amount=9999 — victim browsers silently execute the request
• Caching of Sensitive Data: GET responses are cached by browsers and CDNs — financial data, personal info
may be cached

EXAMPLE GET vs POST for sensitive data

EXAMPLE | GET vs POST

# Vulnerable: password in URL (visible in logs)

GET /login?username=alice&password;=secret123 HTTP/1.1

# Secure: credentials in POST body over HTTPS

POST /login HTTP/1.1

Content-Type: application/json

{"username": "alice", "password": "secret123"}

POST Method — Security Issues

• Mass Assignment: APIs that blindly bind POST body to database objects can be exploited to set hidden fields
(e.g., isAdmin=true)
 • CSRF on POST: Without CSRF tokens, attackers can create forms that silently POST to your application from any
origin
• Unrestricted File Upload: POST endpoints accepting files without type/size validation allow malware uploads

EXAMPLE | Mass Assignment

# Vulnerable: isAdmin can be set by attacker

POST /api/users/update HTTP/1.1

{"name": "Alice", "isAdmin": true, "role": "superuser"}

# Secure: whitelist only allowed fields on server side

# Only accept: name, email — ignore isAdmin entirely

DELETE Method — Security Issues

• Missing Authorization: If DELETE endpoints only check authentication but not authorization, any user can delete
others' data
• IDOR: DELETE /api/posts/123 — changing 123 to another ID deletes other users' posts

PATCH Method — Security Issues

• Insufficient Validation: PATCH accepts partial updates — developers often add fewer validation rules than PUT,
creating injection opportunities
• Race Conditions: Concurrent PATCH requests on the same resource can cause inconsistent state

2.3 HTTP Parameters & Security

1. URL Parameters
URL parameters (query strings) appear after "?" in a URL: /search?q=test&page;=2

• SQL Injection: /products?id=1 OR 1=1-- returns all records

• Path Traversal: /download?file=../../etc/passwd reads system files
• Open Redirect: /login?redirect=[Link] redirects after login
• Insecure Direct Object Reference: /invoice?id=1001 → change to 1002

2. HTTP Headers

Header Security Risk

Authorization Bearer tokens/API keys — must use HTTPS; token theft via MITM if HTTP

Cookie Session tokens — must have HttpOnly, Secure, SameSite flags set

Host Host injection — modify to bypass virtual host routing or cache poisoning

X-Forwarded-For IP spoofing — attackers forge this to bypass IP-based rate limiting

Referer Leaks sensitive URLs to external sites — avoid putting tokens in URLs

Content-Type MIME confusion — wrong type can cause XSS or deserialization attacks

CORS headers Access-Control-Allow-Origin: * allows any origin to read your API responses

3. Cookies

HTTP HEADERS | Cookie Security

# Vulnerable cookie (no security flags)

Set-Cookie: session=abc123

# Secure cookie (all flags set)

 Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=3600

# HttpOnly = JavaScript cannot read this cookie (prevents XSS theft)

# Secure = Only sent over HTTPS connections

# SameSite = Strict/Lax prevents Cross-Site Request Forgery (CSRF)

# Max-Age = Automatic expiration limits session duration

4. Request Body
• SQL Injection: {"username": "admin'--"} bypasses authentication
• XSS via stored input: {"comment": "[Link]='[Link]?c='+[Link]"}
• XXE (XML External Entity): XML bodies with malicious entity references
• Deserialization attacks: Malicious serialized objects in JSON/XML body execute code on server
• Large payloads: Sending gigabyte-sized bodies causes Denial of Service (buffer overflow)

2.4 Sample Vulnerable API Request — Security Analysis

Vulnerability Security Impact

IDOR via userId Changing userId=105 to userId=1 could expose any user's profile — no ownership
verification

JWT in URL Token in query string gets logged in server logs, browser history, Referer headers — token
theft risk

debug=true Parameter Debug mode exposes stack traces, internal paths, DB queries — information disclosure

Cookie: admin=false Client-side authorization flag — attacker can forge Cookie: admin=true to escalate
privileges

X-Forwarded-For spoofing If server trusts this header for rate limiting, attacker can bypass by setting [Link]

Weak JWT Algorithm HS256 with weak secret is brute-forceable — should use RS256 with public/private key
pair
CHAPTER 3

VAPT & OWASP Top 10

Vulnerability Assessment & Penetration Testing, plus the most critical web application security risks

3.1 What is VAPT?

Component Description

Vulnerability Assessment (VA) Goal: Identify and catalogue vulnerabilities without exploiting them. How:
Automated scanners (Nessus, OpenVAS, Qualys) scan systems for known CVEs,
misconfigurations, outdated software. Output: Prioritized list of vulnerabilities with
severity ratings (CVSS scores). Analogy: Like a doctor running tests to find all
possible ailments.

Penetration Testing (PT) Goal: Actively exploit vulnerabilities to determine real-world impact. How: Manual +
automated exploitation using tools like Metasploit, Burp Suite, SQLMap. Output:
Evidence of successful exploits, data accessed, systems compromised. Analogy:
Like actually breaking a lock to prove it can be broken.

How VAPT Strengthens Security Posture

• Proactive Risk Identification: Finds vulnerabilities before attackers do — shifts from reactive to proactive security
• Evidence-Based Prioritization: CVSS scores and exploit POCs help prioritize which vulnerabilities to fix first
• Regulatory Compliance: PCI-DSS, HIPAA, ISO 27001 require regular penetration testing as a compliance
requirement
• Developer Education: Detailed reports teach developers what patterns to avoid — reduces future vulnerabilities
• Board-Level Reporting: Quantifies risk in business terms — enables informed security investment decisions
• Validates Security Controls: Tests whether existing firewalls, WAFs, and monitoring actually work as intended

3.2 OWASP Top 10 — Most Critical Web Vulnerabilities

The OWASP Top 10 is the definitive list of the most critical web application security risks, maintained by the Open
Web Application Security Project. Every security professional must understand these.

A01 Broken Access Control — #1 Vulnerability

Scenario Details

Example 1: IDOR GET /api/orders/1234 — User can change order ID to view others' orders. No authorization
check verifies the order belongs to the requesting user.

Example 2: Privilege Normal user adds &role;=admin to account update request. Server trusts client-supplied role
Escalation without server-side validation.

Prevention Server-side authorization checks on every request. Deny by default. Log and alert on access
control failures. Use indirect object references (random UUIDs instead of sequential IDs).

A02 Cryptographic Failures (Sensitive Data Exposure)

Scenario Details

Example 1: Cleartext Database stores passwords as MD5 hashes. MD5 is cryptographically broken — rainbow
Storage tables crack billions of common passwords in seconds.

Example 2: HTTP Login form submits credentials over HTTP (not HTTPS). Attacker on the same Wi-Fi uses
Transmission Wireshark to capture cleartext username and password.
Prevention Use bcrypt/Argon2 for password hashing. Force HTTPS with HSTS. Encrypt PII with AES-256.
Never store unnecessary sensitive data. Use TLS 1.2+ for all communications.

A03 Injection

SQL INJECTION | Example & Fix

# Vulnerable query:

query = "SELECT * FROM users WHERE username='" + username + "'"

# Attacker input: username = admin'--

# Resulting query: SELECT * FROM users WHERE username='admin'--'

# The -- comments out the password check → full admin bypass

# Secure: parameterized query

query = "SELECT * FROM users WHERE username = ?"

[Link](query, (username,)) # Input never interpreted as SQL

Type Impact

SQL Injection Modifies database queries. Can read all data, bypass auth, delete tables (DROP TABLE), or
execute OS commands

Command Injection ping $(cat /etc/passwd) — OS commands injected via unsanitized system() calls

LDAP Injection Manipulates LDAP queries to bypass authentication or extract directory data

NoSQL Injection MongoDB: {"username": {"$gt": ""}} matches all users — bypasses login

A07 Identification and Authentication Failures

• Brute Force: No account lockout allows unlimited password guesses — automated tools can try millions
• Credential Stuffing: Using breach databases to try known username/password combinations on your app
• Weak Session Tokens: Predictable session IDs (sequential numbers) allow session hijacking
• Session Fixation: Attacker forces a known session ID before login — after victim logs in, attacker owns the session
• Missing MFA: Single factor authentication has no defense against phished or leaked passwords

A03 (XSS) Cross-Site Scripting

An attacker injects malicious scripts into web pages viewed by other users. The script executes in the victim's browser
with full access to their session, DOM, and cookies.

STORED XSS | Attack & Prevention

# Attacker posts a comment with malicious script:

# [Link]="[Link]

# When any user views the page, their session cookie is sent to [Link]

# Attacker uses stolen cookie to impersonate victim

# Prevention: encode output — never insert untrusted data into HTML directly

# Safe: html_escape(user_comment) inside a tag

Other Key OWASP Vulnerabilities

Vulnerability Description

A04: Insecure Design Security not considered during architecture phase. Threat modeling and secure design
patterns must be applied from day one.

A05: Security Misconfiguration Default credentials, open cloud storage, verbose error messages, unnecessary features
enabled, missing security headers.
A06: Vulnerable Components Using libraries with known CVEs. Example: Log4Shell (CVE-2021-44228) affected millions
of Java apps worldwide.

A08: Software/Data Integrity Unsigned updates, insecure deserialization, CI/CD pipeline compromise. SolarWinds
attack vector.

A09: Security Logging Failures No logs for login failures, no alerts on suspicious activity, logs not protected from
tampering.

A10: SSRF Server-Side Request Forgery — server makes HTTP requests to attacker-controlled URLs,
exposing internal services.
CHAPTER 4

Security Reconnaissance Tools

Wappalyzer, [Link], BuiltWith, and Shodan — technology fingerprinting and exposure assessment

4.1 Why Reconnaissance Tools Matter

Attackers research their targets before attacking. Understanding what technologies a website uses, which versions are
deployed, and what is exposed on the internet is the first step in any attack. Security professionals use the same tools
to understand their own attack surface.

4.2 Tool Overview

Tool Type Primary Use

Wappalyzer Browser extension + API Detects 1500+ web technologies: CMS, frameworks, server software,
analytics, CDN, payment processors

[Link] Browser extension + CLI Specifically scans for JavaScript libraries with known CVEs — jQuery,
Angular, Bootstrap, etc.

BuiltWith Web portal + API Comprehensive tech stack profiling with historical data — shows what
technologies were used over time

Shodan Web search engine + API Indexes internet-connected devices — finds exposed servers, IoT
devices, cameras, industrial systems

4.3 Wappalyzer — Technology Detection

Installation: Add the Wappalyzer extension from the Chrome Web Store or Firefox Add-ons. Click the icon on any
website to see its technology stack.

Finding Security Implication

Outdated CMS (WordPress 4.x) Check WPScan database for known vulnerabilities. Old WordPress versions have
thousands of CVEs including RCE, SQL injection, XSS

Apache 2.2.x detected Apache 2.2 is EOL (End of Life) — no security patches. Check for CVE-2017-7679,
CVE-2017-9798 (Optionsbleed)

PHP 5.x detected PHP 5.x is EOL. Vulnerable to numerous CVEs. Object injection, heap overflow, type
juggling attacks

jQuery 1.x detected [Link] flags these — multiple XSS vulnerabilities in jQuery < 3.5.0 via .html(),
.parseHTML()

Cloudflare/WAF detected Helps plan bypass techniques — test for WAF evasion. Confirms DDoS protection is in
place

4.4 [Link] — JavaScript CVE Detection

TERMINAL | [Link] output example

# CLI usage — scan a local project

retire --path ./src

# Scan a live website

retire --url [Link]

# Output example:
 jquery 1.11.3 has known vulnerabilities:

severity: medium; CVE: CVE-2015-9251

XSS vulnerability in [Link]()

bootstrap 3.3.7 has known vulnerabilities:

severity: medium; CVE: CVE-2018-14041

XSS via data-template, data-content, data-title

4.5 Shodan — Internet Exposure Assessment

Shodan is a search engine for internet-connected devices. It continuously scans the entire internet and indexes
banners, service information, and vulnerability data. For security teams, it reveals what an attacker can see about your
organization from the outside.

SHODAN | Example search queries

# Find all servers at a specific organization

org:"Tata Consultancy Services"

# Find servers running a specific software version

product:"Apache httpd" version:"2.2"

# Find servers with open RDP port (common ransomware vector)

port:3389 country:IN

# Find MongoDB instances with no authentication

product:"MongoDB" "MongoDB Server Information"

# Find SSL certificates for a domain

[Link]:*.[Link]

■ IMPORTANT — Ethical Use: Only use Shodan to research systems you own or have explicit permission to test.
Accessing or exploiting systems found via Shodan without permission is illegal. Organizations should regularly
Shodan-search their own IP ranges to check exposure.

4.6 Website Technology Assessment — 5 Sample Sites

Website Technologies Detected Security Findings

[Link] Cloudflare CDN, React, [Link], nginx, [Link]: Check React version for CVEs. Cloudflare
Let's Encrypt SSL provides DDoS protection but doesn't patch app
vulnerabilities.

[Link] Shopify platform, jQuery 1.x, Bootstrap, [Link]: jQuery 1.x has known XSS CVEs. Shopify
Google Analytics handles PCI-DSS but client-side libraries need
updating.

[Link] Akamai CDN, Java/Spring backend, Tracking pixels collect behavioral data — privacy
React, Google Tag Manager compliance risk (GDPR). WAF present.

[Link] PHP backend, Apache, Cloudflare, older PHP version not disclosed in headers (good).
Bootstrap version Shodan: Check for exposed admin panels on
subdomains.

[Link] nginx, Java, various old JS libraries, no [Link] flags multiple outdated libraries. No WAF
WAF detected means direct access to application layer.
CHAPTER 5

Authentication & Session Security Testing

Login security, logout, forgot password flows, session management, and brute-force protection

5.1 Login Security Testing

Test Case 1: Credential Validation

Test ID Test Case Expected Result Result

TC-LOGIN-01 Valid credentials login Enter correct email + password → Redirect to Pass
dashboard. Token/session created.

TC-LOGIN-02 Invalid password Enter wrong password → Generic error "Invalid Pass
credentials". No info about which field is wrong.

TC-LOGIN-03 Non-existent user Enter unregistered email → Same generic error as wrong Critical
password (no user enumeration)

TC-LOGIN-04 Empty fields Submit with blank fields → Client-side and server-side Pass
validation errors shown

TC-LOGIN-05 SQL injection in email Enter admin'-- → Request rejected, error logged, no DB Pass
error shown

TC-LOGIN-06 XSS in username field Enter alert(1) → Input sanitized, script not executed Pass

Test Case 2: Brute Force Protection

• Account Lockout: After 5–10 failed attempts, account should lock for a time-based period (progressive delays or
15-minute lockout)
• Rate Limiting: IP-based or account-based rate limiting — max 10 requests/minute to /login endpoint
• CAPTCHA: Triggered after 3–5 failed attempts to prevent automated attacks
• Lockout Notification: User receives email alert when account is locked
• Admin Unlock: Mechanism for account owners to unlock via email verification

Test Case 3: Error Message Analysis

■ User Enumeration via Error Messages

ERROR MESSAGES

VULNERABLE: "That email address is not registered" ← Confirms valid emails

VULNERABLE: "Incorrect password for alice@[Link]" ← Confirms email exists

SECURE: "Invalid email or password" ← Same message for all failures

WHY IT MATTERS: Attackers use enumeration to build lists of valid accounts

for credential stuffing attacks using breach databases.

5.2 Logout Security Testing

Test Area Details & Test Method

Server-Side Session After logout, the server must destroy the session token. Test: Copy session cookie before
Invalidation logout → logout → use copied cookie → should receive 401 Unauthorized. Common
failure: server returns 200 OK with session still valid.
Token Blacklisting (JWT) JWTs are stateless — server must maintain a blacklist of invalidated tokens. Without this, a
stolen JWT remains valid until its expiry time even after logout.

Clear Client-Side Storage Logout must clear cookies, localStorage, sessionStorage, and IndexedDB. Verify via
browser DevTools after logout — no tokens should remain.

Re-authentication Protection After logout, pressing browser Back button should not restore the logged-in state. Test with
Cache-Control: no-store headers.

Concurrent Sessions Logging out of one device should optionally invalidate all active sessions. Offer "Logout all
devices" functionality for security-sensitive apps.

5.3 Forgot Password Flow Security

Security Control Description & Test

Password Reset Token Entropy Token must be cryptographically random with at least 128 bits of entropy. Predictable
tokens (sequential IDs, timestamps, MD5 of email) can be brute-forced.

Token Expiration Reset tokens must expire within 15–60 minutes. Tokens that never expire can be used
days/months later after a link is forwarded or intercepted.

Single Use Tokens Token must be invalidated after use. Test: Use a reset link twice — second use should
return "Token already used or expired."

No Token in URL (ideal) Tokens in URLs appear in server logs and Referer headers. Better: POST token in
body or use cookie-based flow.

Rate Limiting on Reset No rate limiting allows attackers to flood victims with password reset emails (email
bombing / account enumeration).

Account Enumeration Response should always say "If your email is registered, you will receive a reset link" —
never confirm/deny account existence.

5.4 Session Management Security

SECURITY CHECKLIST | Session management tests

# Security test checklist for sessions

1. Session token length >= 128 bits (entropy)

2. Cookie flags: HttpOnly; Secure; SameSite=Strict

3. Session expires after inactivity (15-30 min for sensitive apps)

4. New session ID issued on privilege change (login, role change)

5. Session invalidated on logout (server-side)

6. No session tokens in URLs or logs

7. Session fixation prevention (regenerate ID after login)

# Test session expiry

# 1. Log in, note session cookie value

# 2. Wait for inactivity timeout period

# 3. Send request with old cookie

# 4. Expected: 401 Unauthorized / redirect to login

# 5. Vulnerable: Request succeeds with expired session

CHAPTER 6

SSL/TLS Security & Compliance Frameworks

Testing SSL/TLS configurations, detecting weaknesses, and understanding compliance requirements

6.1 SSL/TLS Fundamentals

Protocol Version Security Status

TLS 1.3 (2018) RECOMMENDED — Strongest. Removed weak ciphers, 0-RTT resumption. Use this.

TLS 1.2 (2008) ACCEPTABLE — Widely supported. Must disable weak cipher suites (RC4, 3DES, export).

TLS 1.1 (2006) DEPRECATED — Officially deprecated in RFC 8996. Disable immediately.

TLS 1.0 (1999) DEPRECATED — Vulnerable to BEAST, POODLE. PCI-DSS non-compliant since 2018.

SSL 3.0 (1996) CRITICAL — DISABLE — Vulnerable to POODLE attack. Should not exist on any server.

SSL 2.0 (1995) CRITICAL — DISABLE — Completely broken. Multiple critical vulnerabilities.

6.2 Key SSL/TLS Vulnerabilities

Vulnerability Description & Fix

BEAST (2011) Browser Exploit Against SSL/TLS. Exploits CBC mode in TLS 1.0. Allows MITM to decrypt HTTPS
cookies. Fix: Disable TLS 1.0, use AEAD ciphers.

POODLE (2014) Padding Oracle On Downgraded Legacy Encryption. Exploits SSL 3.0 padding. Can decrypt ~1
byte per 256 requests. Fix: Disable SSL 3.0 entirely.

HEARTBLEED (2014) OpenSSL buffer over-read. Leaks up to 64KB of server memory per request — can expose private
keys, passwords, session tokens. CVE-2014-0160.

FREAK (2015) Factoring RSA Export Keys. Downgrades to weak "export-grade" 512-bit RSA. Crackable in hours
with cloud computing. Fix: Disable export cipher suites.

DROWN (2016) Decrypting RSA with Obsolete and Weakened eNcryption. SSLv2 allows decryption of TLS
sessions. Fix: Disable SSLv2 on ALL servers sharing the private key.

SWEET32 (2016) 64-bit block cipher birthday attack affecting 3DES and Blowfish in TLS. Fix: Disable 3DES ciphers.

Expired Certificate Browser shows security warning, users leave, automated systems fail. Use Let's Encrypt with
auto-renewal.

Missing HSTS Without HTTP Strict Transport Security, users can be downgraded to HTTP via SSL stripping. Add:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

6.3 SSL Labs Testing & Secure Configuration

NGINX CONFIG | Secure SSL/TLS configuration

# Recommended SSL configuration (nginx)

ssl_protocols TLSv1.2 TLSv1.3;

# Strong cipher suites only — disable weak ones

ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384

:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
 # Server prefers its cipher order (prevents downgrade)

ssl_prefer_server_ciphers off;

# HSTS — tell browsers to always use HTTPS

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

# Enable OCSP Stapling for faster cert validation

ssl_stapling on;

ssl_stapling_verify on;

6.4 Compliance Frameworks

Framework Description, Scope & Requirements

PCI-DSS Payment Card Industry Data Security Standard. For: Any business that processes credit/debit cards.
Key SSL/TLS requirements: Disable TLS 1.0/1.1; use TLS 1.2+; quarterly vulnerability scans; annual
penetration testing. Penalty: $5,000–$100,000/month fines; card processing privileges revoked.

HIPAA Health Insurance Portability and Accountability Act. For: Healthcare providers, insurers, business
associates handling PHI. Key requirements: Encryption of PHI at rest and in transit; access controls;
audit logs; incident response plan. Penalty: $100–$50,000 per violation; up to $1.9M/year per category.

GDPR General Data Protection Regulation. For: Any organization processing personal data of EU residents.
Key requirements: Data minimization, right to erasure, breach notification within 72 hours, Privacy by
Design. Penalty: Up to 4% of global annual revenue or €20M, whichever is higher.

ISO 27001 International Standard for Information Security Management. For: Any organization wanting
internationally recognized security certification. Key requirements: Risk assessment, security controls
across 14 domains, regular audits, ISMS. Benefit: Demonstrates security maturity to clients.

SOC 2 Service Organization Controls 2. For: Technology companies and SaaS providers handling customer
data. Key requirements: Security, Availability, Processing Integrity, Confidentiality, Privacy trust service
criteria. Benefit: Required by enterprise clients.

OWASP ASVS Application Security Verification Standard. For: Web application development teams and security
testers. Key requirements: Three levels (L1=basic, L2=standard, L3=advanced) of security controls.
Benefit: Provides concrete checklist for secure application development.
CHAPTER 7

Google Dorking & OSINT Techniques

Advanced search operators to discover exposed sensitive data, vulnerable systems, and security
misconfigurations

7.1 What is Google Dorking?

Google Dorking (also called Google Hacking) uses advanced search operators to find specific information indexed by
search engines that is not easily found through normal searches. Security professionals use it for OSINT (Open
Source Intelligence) and attack surface discovery. The technique exploits the fact that misconfigured servers expose
sensitive files to web crawlers.

■ ETHICAL & LEGAL NOTICE: Google Dorking techniques must only be used on systems you own or have explicit
written authorization to test. Unauthorized access to computer systems — even via publicly indexed information — is
illegal in most countries. The Computer Fraud and Abuse Act (CFAA) in the US, and similar laws globally, apply.

7.2 Core Google Dork Operators

Operator Usage & Example

site: Restrict search to a specific domain. site:[Link] admin — finds admin pages on [Link]

intitle: Search in page title. intitle:"index of" — finds open directory listings

inurl: Search in URL. inurl:admin inurl:login — finds admin login pages

intext: Search in page body text. intext:"password" intext:"username" — finds exposed credentials

filetype: Search for specific file type. filetype:sql — finds exposed database dumps

ext: Search by file extension. ext:env — finds .env configuration files

"string" Exact phrase match. "DB_PASSWORD" — finds pages with exact string

-term Exclude results containing term. site:[Link] -www — finds subdomains

OR Combine multiple terms. inurl:admin OR inurl:administrator

7.3 Practical Dork Queries by Category

Exposed Files & Configuration
GOOGLE DORK | Exposed files & configuration

# Environment files with credentials

filetype:env "DB_PASSWORD"

inurl:.env "APP_KEY="

# Database backup files

filetype:sql intext:"INSERT INTO" intext:"users"

filetype:bak inurl:backup

# Configuration files

filetype:xml inurl:config "password"

filetype:json inurl:config "api_key"

filetype:yaml "password:" site:[Link]

 # Log files with sensitive data

filetype:log intext:"password" intext:"error"

Open Directory Listings

GOOGLE DORK | Open directory listings

# Open directories (often expose all files in a folder)

intitle:"index of" "parent directory"

intitle:"index of" site:[Link]

# Specific directory types

intitle:"index of" "uploads"

intitle:"index of" "backup"

intitle:"index of" ".git"

# Find Git repositories accidentally exposed

inurl:".git" intitle:"index of"

# Critical: git history can contain deleted secrets, old credentials

Exposed Admin Panels & Login Pages

GOOGLE DORK | Admin panels & dashboards

# Admin login pages

inurl:admin intitle:"login" site:[Link]

inurl:wp-admin site:[Link]

# phpMyAdmin (database management)

inurl:phpmyadmin intitle:"phpMyAdmin"

# Exposed dashboards

intitle:"Kibana" inurl:5601 # Elasticsearch Kibana

intitle:"Grafana" inurl:3000 # Grafana monitoring

intitle:"Jenkins" inurl:8080 # Jenkins CI/CD

Vulnerability Discovery

GOOGLE DORK | Vulnerability indicators

# Sites with SQL error messages (may be injectable)

intext:"You have an error in your SQL syntax"

intext:"mysql_fetch_array()" "Warning:"

# PHP error messages revealing server paths

intext:"Warning: include(" "on line" "failed to open stream"

# Django debug mode enabled (exposes full code and settings)

intext:"Django Version" intext:"DEBUG = True"

7.4 Defensive Measures Against Google Dorking

Control Implementation

[Link] List directories to block from indexing: Disallow: /admin, Disallow: /config, Disallow: /.env

Google Search Console Use "Remove URLs" tool to de-index accidentally exposed sensitive pages already
indexed
Web Application Firewall Detect and block directory traversal and path disclosure patterns in requests

File Permissions Ensure sensitive files (config, backups, logs) are not in web-accessible directories

Regular Dorking Audits Run dork queries against your own domain monthly. Set up Google Alerts for company
name + "password" etc.

HTTP Headers X-Content-Type-Options, X-Robots-Tag: noindex for admin areas

CHAPTER 8

Interview Questions & Answers

Standard security testing interview questions with detailed model answers

Category: Fundamental Concepts

Q1. What is the CIA Triad and why is it important in cybersecurity?

CIA stands for Confidentiality (only authorized users access data), Integrity (data is accurate and unaltered), and
Availability (systems are accessible when needed). It is the foundational model for designing and evaluating security
controls. Every security decision maps to one or more of these pillars. Example: Encryption protects confidentiality;
digital signatures protect integrity; redundancy/load balancing ensures availability.

Q2. Define cybersecurity and differentiate between VA and Penetration Testing.

Cybersecurity is the practice of protecting systems, networks, and data from digital attacks. Vulnerability
Assessment (VA) identifies and catalogues vulnerabilities using automated tools — no exploitation. Penetration
Testing actively exploits vulnerabilities to determine real-world impact. VA tells you what doors might be unlocked;
PT proves they can actually be opened.

Q3. What is the difference between authentication and authorization?

Authentication verifies WHO you are (login: username + password, MFA). Authorization determines WHAT you are
allowed to do after authentication (access control: can this user view /admin?). A logged-in user (authenticated) may
not be allowed to access admin functions (not authorized). Breaking this distinction is Broken Access Control —
OWASP #1.

Q4. Explain the concept of "defense in depth."

Defense in depth is a security strategy that uses multiple layered security controls so that if one fails, others still
protect the system. Example layers: Perimeter firewall → IDS/IPS → WAF → Application-level input validation →
Database access controls → Encryption → Audit logging. No single control is perfect, but multiple layers make
attacks exponentially harder.

Category: OWASP & Web Vulnerabilities

Q5. Explain SQL Injection with an example and how to prevent it.
SQL Injection occurs when user input is directly concatenated into a SQL query without sanitization. Example: query
= "SELECT * FROM users WHERE user='" + input + "'". If input = admin'-- the query becomes SELECT * FROM
users WHERE user='admin'-- which bypasses the password check. Prevention: Use parameterized
queries/prepared statements, input validation, least-privilege DB accounts, WAF rules.

Q6. What is XSS? Distinguish between Reflected, Stored, and DOM-based XSS.
XSS (Cross-Site Scripting) injects malicious scripts into pages viewed by other users. Reflected XSS: Malicious
script in URL parameter — server reflects it in response (non-persistent). Stored XSS: Script saved in DB (e.g.,
comment) — executes for every visitor (most dangerous). DOM-based XSS: Client-side JavaScript writes attacker
data to DOM without sanitization — server not involved. All enable session hijacking, credential theft, keylogging.

Q7. What is IDOR? Provide a real-world example.

IDOR (Insecure Direct Object Reference) occurs when an application uses user-controllable input to access objects
without authorization checks. Example: GET /api/invoice/1234 — attacker changes 1234 to 1235, 1236 etc. and
downloads other users' invoices. Prevention: Map external IDs to internal ones server-side (indirect references),
verify ownership on every request, use UUIDs instead of sequential IDs.

Q8. What is CSRF and how is it prevented?

CSRF (Cross-Site Request Forgery) tricks authenticated users into submitting malicious requests. Example:
Attacker creates a page with an invisible image tag pointing to [Link]/transfer?to=attacker&amount;=1000 —
 when logged-in user visits, their browser automatically sends the request with valid cookies. Prevention: CSRF
tokens (unique per session, per form), SameSite=Strict cookies, checking Origin/Referer headers, re-authentication
for sensitive actions.

Category: HTTP & API Security

Q9. What security headers should every web application implement?

Key security headers: Content-Security-Policy (CSP) — restricts resource loading to prevent XSS;
X-Frame-Options: DENY — prevents clickjacking; X-Content-Type-Options: nosniff — prevents MIME-type sniffing;
Strict-Transport-Security (HSTS) — forces HTTPS; Referrer-Policy — controls Referer header leakage;
Permissions-Policy — restricts browser features. Test with [Link].

Q10. What vulnerabilities can occur due to improper cookie handling?

Missing HttpOnly flag: JavaScript can read cookies via [Link] — XSS can steal session tokens. Missing
Secure flag: Cookie sent over HTTP — interceptable by MITM. Missing SameSite: Enables CSRF attacks. Missing
expiry: Sessions never expire — stolen tokens remain valid indefinitely. Overly broad domain/path: Cookie sent to all
subdomains, expanding attack surface.

Q11. What is a JWT and what security issues can arise?

JWT (JSON Web Token) is a compact, signed token for stateless authentication. Security issues: Algorithm
confusion (alg:none attack — server accepts unsigned tokens); weak secret brute-forcing (short HMAC secrets);
sensitive data in payload (base64 is not encryption — anyone can read claims); missing expiry (tokens valid
forever); no revocation mechanism (logout doesn't invalidate token). Best practices: Use RS256, strong secrets,
short expiry, token blacklist for logout.

Category: Tools & Methodology

Q12. What tools do you use for web application security testing?
Proxy/Scanner: Burp Suite Professional (intercepting proxy, scanner, intruder, repeater). OWASP ZAP (free
alternative). Recon: Nmap (network scanning), Shodan (internet-facing assets), Wappalyzer/BuiltWith (tech
fingerprinting), [Link] (vulnerable JS). Exploitation: SQLMap (SQL injection automation), Metasploit (exploit
framework). SSL: SSL Labs, [Link]. Fuzzing: FFUF, Dirb, Gobuster (directory enumeration).

Q13. How do you approach a web application penetration test?

1. Planning: Scope definition, rules of engagement, legal agreement. 2. Reconnaissance: OSINT, subdomain
enumeration, tech fingerprinting, Google dorking. 3. Scanning: Automated scan (Burp Suite, ZAP), directory
bruteforce, port scan. 4. Manual Testing: Test all OWASP Top 10 manually, business logic testing,
authentication/authorization. 5. Exploitation: Exploit confirmed vulnerabilities, document proof. 6. Reporting:
Executive summary, technical findings with CVSS scores, remediation steps. 7. Retest: Verify fixes after
remediation.

Q14. How does VAPT contribute to an organization's security posture?

VAPT provides: Proactive risk identification before attackers find vulnerabilities; prioritized remediation roadmap
based on CVSS severity; compliance evidence for PCI-DSS, HIPAA, ISO 27001; validates effectiveness of existing
security controls; educates developers on secure coding through detailed findings; quantifies security risk for
board-level decision making; establishes security baseline for measuring improvement over time.

Category: SSL/TLS & Infrastructure

Q15. What are the key differences between SSL and TLS?
SSL (Secure Sockets Layer) is the predecessor to TLS (Transport Layer Security). SSL 2.0 and 3.0 are completely
broken and should be disabled. TLS 1.0 and 1.1 are deprecated (RFC 8996, 2021). TLS 1.2 is currently acceptable
with proper cipher configuration. TLS 1.3 (2018) is the recommended standard — faster handshake, removed legacy
ciphers, mandatory forward secrecy. The term "SSL certificate" is a misnomer — they are actually TLS certificates.
Q16. What are weak cipher suites and why are they dangerous?
Weak cipher suites use cryptographic algorithms that are vulnerable to attacks: RC4 (statistical biases — stream
cipher broken); 3DES (SWEET32 birthday attack — 64-bit blocks); Export-grade ciphers (FREAK attack — 40/56-bit
keys breakable in hours); NULL ciphers (no encryption at all). Weak suites allow attackers to decrypt HTTPS traffic
via MITM. Always configure: ECDHE key exchange, AESGCM or ChaCha20-Poly1305 ciphers, SHA-256+ for MAC.

Q17. What is HSTS and why is it important?

HSTS (HTTP Strict Transport Security) is a response header that tells browsers to always use HTTPS for this
domain, for a specified max-age. Without HSTS: Attacker performs SSL stripping — downgrades HTTPS to HTTP
on first connection, intercepting credentials. With HSTS: Browser refuses HTTP connections and shows error
instead. Best practice: max-age=31536000; includeSubDomains; preload — submit to browser preload lists for
protection on very first visit.

Category: Advanced & Scenario-Based

Q18. You discover a login page with no rate limiting. What is your testing approach?
1. Verify with manual test — try 20+ wrong passwords, confirm no lockout. 2. Use Burp Intruder: intercept login
POST, set payload position on password field, load wordlist ([Link]). 3. Document: HTTP 200 on correct
password vs HTTP 401 on wrong (different response length/time = oracle). 4. Escalate: Try with known breached
passwords for target users (OSINT from LinkedIn). 5. Report as HIGH severity: No rate limiting, no account lockout,
no CAPTCHA — trivially brute-forceable. Recommend: Implement progressive delays, account lockout after 5
attempts, CAPTCHA, MFA.

Q19. How would you test for sensitive data exposure in a web application?
1. Check all API responses for unnecessary data (full card number, SSN, passwords). 2. Test HTTPS enforcement
— try HTTP, check for redirect vs. content on HTTP. 3. Check cookies for Secure flag — test in HTTP context. 4.
Search for data in local storage (DevTools → Application → Local Storage). 5. Check error messages — do they
expose stack traces, DB connection strings, file paths? 6. Google dork the site for exposed files: site:[Link]
filetype:log. 7. Check API responses for over-fetching (returning full user object when only name needed). 8. Test
caching headers — sensitive pages should have Cache-Control: no-store.

Q20. What is the OWASP Testing Guide and how do you use it?
The OWASP Testing Guide (OTG) is a comprehensive reference for web application security testing with specific
test cases for each category of vulnerability. Structure: 12 categories including Information Gathering, Configuration
Testing, Identity Management, Authentication Testing, Authorization Testing, Session Management, Input
Validation, Error Handling, Cryptography, Business Logic, Client-Side Testing. Each test case has: Objective, test
technique, specific payloads, expected results, and remediation. It serves as a checklist to ensure complete
coverage during an assessment.

■ Practice Test Summary

• Chapter 1: Define cybersecurity; explain CIA Triad; give 2 examples of security measures.
• Chapter 2: Analyze an API request for vulnerabilities; explain HTTP method risks.
• Chapter 3: How does VAPT strengthen security posture? Give 2 OWASP vulnerability examples.
• Chapter 4: Assess 5 websites using Wappalyzer/[Link]/BuiltWith/Shodan.
• Chapter 5: Generate security test cases for login, logout, and forgot password.
• Chapter 6: Test a live site SSL configuration using SSL Labs; list compliance types.
• Chapter 7: Apply Google Dorking to find exposed data; discuss ethical considerations.

SECURITY TESTING GUIDE — Complete Reference | Cybersecurity • VAPT • OWASP • SSL • Dorking
Security Testing Training Guide • Confidential