# A structured recon walkthrough
# (what interviewers expect when they ask
#  "how do you start a web app test?")

Step 1: Scope confirmation
  - Confirm in-scope hosts, subdomains, endpoints
  - Note out-of-scope services
  - Never test without written authorization

Step 2: Passive recon
  - WHOIS, DNS records, MX/SPF
  - Shodan, Censys for exposed services
  - Google dorks for public documents

Step 3: Active recon
  - nmap -sV -sC -p- 10.10.10.10
  - gobuster dir -u https://target -w wordlist.txt
  - Wappalyzer / WhatWeb for tech fingerprinting

Step 4: Map the attack surface
  - Endpoints and expected auth
  - High-value targets (auth, payment, admin)
  - Document everything before exploitation

# The mistake: "I run nmap and then Metasploit."
# The fix: explain methodology and *why* each step exists.

# Why is this SQLi 8.1 and not 9.8?
# Interviewers ask this to see if you understand scoring.

Example: SQL injection on an authenticated
/profile?id= endpoint

Attack Vector (AV):        Network    (0.85)
Attack Complexity (AC):    Low        (0.77)
Privileges Required (PR):  Low        (0.62)
User Interaction (UI):     None       (0.85)
Scope (S):                 Unchanged
Confidentiality (C):       High       (0.56)
Integrity (I):             High       (0.56)
Availability (A):          None       (0.00)

Derived base score: ~8.1 (High)

# The mistake: memorising "SQLi = 9.8".
# The fix: explain the components. Pre-auth pushes higher.
# Read-only data pushes lower.

# In the interview, say:
# "I'd classify the vector and privileges, reason about
#  C/I/A impact, then compute or look up the score."

# "What's your experience with web app testing?"

❌ Bad answer:
"I can hack anything. I've broken into my friend's
Instagram once. I know all the tools — Burp, Nmap,
Metasploit, everything."

Why it fails:
- Overclaiming without evidence
- Describes unauthorized hacking
- Tool-list without depth
- No methodology

✅ Good answer:
"I focus on web application testing. Over the last
6 months I've completed 40 rooms on TryHackMe and
built a lab with DVWA and OWASP Juice Shop.

My strongest area is OWASP Top 10 testing — I can
walk through SQLi, XSS, and access control end-to-end
with reproduction steps and remediation.

I document every finding in a short report; here's
a link to one on my GitHub."

Why it works:
- Specific and scoped
- Lab-based (legal) evidence
- Clear methodology
- Report discipline shown

# A repeatable structure for explaining findings in
# interviews. Memorise the shape, not the words.

Title:
  SQL injection in /product?id= (numeric parameter)

Severity / CVSS:
  High — 8.1 (derived, not memorised)

Affected component:
  Product listing endpoint
  Unauthenticated

Impact:
  - Full read access to products table
  - Possible read access to users if the same DB
    account has access
  - Not currently exploitable for write access

Reproduction:
  1. GET /product?id=1' OR '1'='1
  2. Response returns all products
  3. Confirm with UNION SELECT username,password
     FROM users--

Remediation:
  - Parameterised queries / prepared statements
  - Least-privilege DB account
  - WAF rule as defence in depth (not the fix)

References:
  OWASP A03:2021 (Injection)
  CWE-89

# Say this in 90 seconds — that's what interviewers want.

# The most important thing to say out loud in an
# ethical hacking interview: confirm scope first.

Ask before testing anything:

1. "Which hosts and subdomains are in scope?"
2. "Are third-party services (SSO, CDN, payment
    gateway) excluded?"
3. "Is authenticated testing allowed? Can I
    create test accounts?"
4. "Are there rate limits or testing windows I
    need to respect?"
5. "Who is the emergency contact if I find a
    critical bug mid-test?"

# The mistake:
#   Jumping to "I'd run nmap and Metasploit"
#   without mentioning authorization.

# The fix:
#   Say explicitly: "before any test, I'd confirm
#   written authorization and scope." Interviewers
#   care about this more than your tool list.

# A good responsible disclosure flow to describe

1. Do not publicly disclose until agreed
2. Report privately to the vendor (email/portal)
3. Include:
   - Clear title and severity
   - Reproduction steps
   - Impact assessment
   - Suggested remediation
   - Your contact details
4. Give a reasonable window (typically 90 days)
5. Agree on disclosure date
6. Publish only after the vendor fixes (or after
   the agreed window with vendor awareness)

# The mistake:
#   "I found a bug in X and tweeted screenshots."
# The fix:
#   "I reported it privately, gave the vendor 90 days,
#    coordinated the timeline."

# Interviewers use this to test judgment and maturity.
# Nail this and you stand out from candidates who
# only know how to find bugs.

# A short report template that shows your work

1. Executive summary
   Two to three sentences for a non-technical reader

2. Scope and methodology
   - What was tested, what wasn't
   - Tools and time spent

3. Findings (one section per finding)
   - Title
   - Severity / CVSS
   - Affected component
   - Impact
   - Reproduction steps
   - Evidence (screenshots, requests)
   - Remediation
   - References (CWE, OWASP)

4. Positive observations
   What was done well — builds client trust

5. Appendix
   Raw tool output, screenshots, logs

# Publish one or two sanitised reports on GitHub.
# Interviewers will reference them.

# How to handle a live demo that breaks — the fix
# interviewers actually score

Scenario: demonstrating an XSS exploit; the payload
doesn't fire.

❌ Bad response:
   - Silent panic, retry three times
   - Blame the lab

✅ Good response:
   1. Narrate: "The payload didn't reflect — let me
      check the response to see if it's escaped."
   2. Run a harmless canary: test
   3. Check the DOM and browser console
   4. Try an encoded payload if filters are present
   5. If still failing: "I'd stop, take a fresh look
      at the response, and re-test after re-checking
      the reflected/context location."

# The interviewer scores your process, not the
# exploit landing. Say what you're doing as you do it.

# The mistake:
#   Treating a failed exploit as a personal failure.
# The fix:
#   Treat it as the moment to show your debugging
#   instinct — that's what they actually want to see.