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

This guide covers all topics from the Security Testing Training Curriculum
SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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 Encryption (AES-256), Access Control Lists,
to authorized individuals. Data must be kept Multi-Factor Authentication, Data masking,
private and protected from unauthorized Role-Based Access Control (RBAC)
disclosure.

■■ Integrity Ensures that information is accurate, Digital signatures, Hash functions

complete, and has not been tampered with (SHA-256), Checksums, Version control,
or modified by unauthorized parties during Database transaction logs, File integrity
storage or transit. monitoring

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

Real-World CIA Triad Violations

Incident Impact Triad Violation

Security Testing Training Guide • Confidential Page 2 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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 (Vulnerability Assessment & Combines automated scanning and manual exploitation to find and validate security
Penetration Testing) weaknesses

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

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

IAST (Interactive Application Combines SAST & DAST — uses agents inside running apps to monitor behavior during
Security Testing) 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

Security Testing Training Guide • Confidential Page 3 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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. The
standard formula is:

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

Security Testing Training Guide • Confidential Page 4 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

CHAPTER 2

HTTP Methods & Parameter Security

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

2.1 HTTP Methods Overview

HTTP (HyperText Transfer Protocol) defines methods that specify the action to be performed on a resource. Each
method has a defined semantics, and misusing or misconfiguring them creates security vulnerabilities.

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

Security Testing Training Guide • Confidential Page 5 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

EXAMPLE | GET vs POST for sensitive data

# 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 (logged in) but not authorization (owns
this resource), any user can delete others' data
• IDOR (Insecure Direct Object Reference): 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

■ URL Parameter Vulnerabilities

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

Security Testing Training Guide • Confidential Page 6 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

• 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
Headers carry metadata about the request/response. Misconfigured headers create significant vulnerabilities.

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
Cookies store session tokens, preferences, and tracking data. Insecure cookie configuration is one of the most
common web vulnerabilities.

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
The request body carries data for POST/PUT/PATCH requests. Vulnerabilities arise from insufficient validation and
sanitization.

■ Request Body Attack Vectors

• SQL Injection: {"username": "admin'--"} bypasses authentication

• XSS via stored input: {"comment": "[Link]='[Link]?c='+[Link]"}

Security Testing Training Guide • Confidential Page 7 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

• XXE (XML External Entity): XML bodies with

• 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 ChatGPT API Security Analysis — Sample Request

Below is a sample vulnerable API request. When analyzed by ChatGPT for security issues, the following critical
vulnerabilities were identified:

SAMPLE VULNERABLE API REQUEST

GET /api/user/profile?userId=105&token;=eyJhbGci...&debug;=true HTTP/1.1

Host: [Link]

Cookie: session=abc123; admin=false

Authorization: Bearer [Link]

X-Forwarded-For: [Link]

Content-Type: application/json

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

Security Testing Training Guide • Confidential Page 8 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

CHAPTER 3

VAPT & OWASP Top 10

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

3.1 What is VAPT?

VAPT (Vulnerability Assessment and Penetration Testing) is a two-phase security evaluation process that
combines automated scanning with manual exploitation to provide a comprehensive view of an organization's security
posture.

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.

Security Testing Training Guide • Confidential Page 9 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

A01: Broken Access Control

The #1 vulnerability. Occurs when restrictions on what authenticated users are allowed to do are not properly enforced.

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 Escalation Normal user adds &role;=admin to account update request. Server trusts
client-supplied role 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)

Failures related to cryptography that lead to exposure of sensitive data. Formerly called "Sensitive Data Exposure."

Scenario Details

Example 1: Cleartext Storage Database stores passwords as MD5 hashes. MD5 is cryptographically broken — rainbow
tables crack billions of common passwords in seconds. A data breach exposes all user
credentials.

Example 2: HTTP Transmission Login form submits credentials over HTTP (not HTTPS). Attacker on the same Wi-Fi uses
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
Untrusted data is sent to an interpreter as part of a command or query, tricking it into executing unintended commands.

SQL INJECTION | Example & Fix

# SQL Injection Example

# 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

Security Testing Training Guide • Confidential Page 10 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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

Weaknesses in authentication mechanisms that allow attackers to compromise passwords, keys, or session tokens.

• 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

# Stored XSS Attack

# Attacker posts a comment with malicious script:

Comment: [script tag]

[Link]="[Link]

[/script tag]

# 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 p 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.

Security Testing Training Guide • Confidential Page 11 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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.

Security Testing Training Guide • Confidential Page 12 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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.

Security Implications of Detected Technologies

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

Security Testing Training Guide • Confidential Page 13 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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

Installation: Install via npm ( npm install -g retire ) or as a browser extension. Scans loaded JavaScript files
against a database of vulnerable versions.

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.

Essential Shodan Search Queries

Security Testing Training Guide • Confidential Page 14 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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 webcams

server: "webcam"

# Find servers with default credentials warning

"default password" port:80

# Find SSL certificates for a domain

[Link]:*.[Link]

■ Important: Ethical Use of Shodan

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.

Shodan is a legitimate tool for asset discovery in authorized security assessments.

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

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

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

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

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

Security Testing Training Guide • Confidential Page 15 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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

Security Testing Training Guide • Confidential Page 16 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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 Critical
as wrong password (no user enumeration)

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

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

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

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

Security Testing Training Guide • Confidential Page 17 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

BURP SUITE | Brute force test setup

# Brute Force Test — Burp Suite Intruder

# Set attack position on password field

POST /login HTTP/1.1

Content-Type: application/json

{"email": "alice@[Link]", "password": "§PASSWORD§"}

# Load password list: [Link] (14M passwords)

# Expected: Account locked after 5 attempts (429 Too Many Requests)

# Vulnerable: 200 OK returned on any attempt without lockout

Test Case 3: Error Message Analysis

■ User Enumeration via 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 Invalidation After logout, the server must destroy the session token. Test: Copy session cookie before
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

The password reset flow is a common attack vector. Weak implementations allow account takeover without knowing
the current password.

Security Testing Training Guide • Confidential Page 18 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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

Security Testing Training Guide • Confidential Page 19 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

CHAPTER 6

SSL/TLS Security & Compliance Frameworks

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

6.1 SSL/TLS Fundamentals

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are cryptographic protocols that provide
encrypted communication over networks. TLS is what makes HTTPS secure.

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 RC4 (temporary) or 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. After collecting
785GB of ciphertext, can recover plaintext. Fix: Disable 3DES ciphers.

Security Testing Training Guide • Confidential Page 20 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

Expired Certificate Browser shows security warning, users leave, automated systems fail. Use Let's Encrypt
with auto-renewal or set calendar reminders 30 days before expiry.

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

6.3 SSL Labs Testing & Improvements

Use Qualys SSL Labs ([Link]/ssltest) to test any public-facing site. The tool provides a letter grade (A+ to F) with
detailed findings.

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

Compliance frameworks are sets of requirements organizations must meet to protect sensitive data. Security testing
helps verify compliance.

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 for non-compliance: $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 (Protected Health Information) 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

Security Testing Training Guide • Confidential Page 21 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

GDPR General Data Protection Regulation For: Any organization processing personal data of EU
residents (regardless of where the org is based) 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 (Information Security Management System) Benefit:
Demonstrates security maturity to clients, enables business with regulated industries

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; demonstrates controls to auditors and
customers

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
covering authentication, session, access control, crypto, etc. Benefit: Provides concrete checklist for
secure application development

Security Testing Training Guide • Confidential Page 22 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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 to unauthorized access.

Always conduct OSINT activities within the scope of an authorized engagement.

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

cache: View Google's cached version of a page — useful even if page is now removed

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

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

Security Testing Training Guide • Confidential Page 23 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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"

ext:log "access denied"

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

Security Testing Training Guide • Confidential Page 24 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

GOOGLE DORK | Admin panels & dashboards

# Admin login pages

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

inurl:wp-admin site:[Link]

inurl:cpanel inurl:login

# 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

Sensitive Data Exposure

GOOGLE DORK | Sensitive data searches

# Credit card data (PCI violation if indexed)

intext:"card number" filetype:xls

# Personal identification data

filetype:xls intext:"ssn" intext:"social security"

# Default credentials pages

intitle:"default password" "change password"

"default username" "default password" inurl:login

# API keys and tokens

"api_key" filetype:txt site:[Link]

"AKIA" filetype:txt # AWS Access Key ID prefix

# Exposed webcams and IoT

inurl:/view/[Link] # NetCam live feeds

intitle:"Live View / - AXIS" # AXIS security cameras

Vulnerability Discovery

Security Testing Training Guide • Confidential Page 25 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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"

# Apache directory listing enabled

intitle:"Apache HTTP Server" intitle:"Test Page"

# 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

Security Testing Training Guide • Confidential Page 26 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

CHAPTER 8

Interview Questions & Answers

Standard security testing interview questions with detailed model answers

The following questions cover all topics from this guide and represent common interview questions for Security
Testing, VAPT, and Cybersecurity roles at junior to mid-level positions.

Category: Fundamental Concepts

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

Answer: 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.

Answer: 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?

Answer: 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."

Answer: 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.

Security Testing Training Guide • Confidential Page 27 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

Answer: 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.
Answer: 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.

Answer: 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?

Answer: 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?

Answer: 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?

Answer: 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?

Answer: 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.

Security Testing Training Guide • Confidential Page 28 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

Category: Tools & Methodology

Q12. What tools do you use for web application security testing?
Answer: 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?

Answer: 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?

Answer: 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?
Answer: 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?
Answer: 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?

Answer: 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

Security Testing Training Guide • Confidential Page 29 of 30

SECURITY TESTING GUIDE — Complete Reference Cybersecurity | VAPT | OWASP | SSL | Dorking

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?
Answer: 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?
Answer: 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?
Answer: 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 Training Guide • Confidential Page 30 of 30