Lab Guide

Task 1.1 — Full vulnerability pass

You are a senior application security auditor. Review the Python
web application below and produce:

1. A numbered list of every vulnerability, each with:
   - CWE ID (e.g., CWE-89 SQL Injection)
   - Exact line numbers
   - Severity (Critical / High / Medium / Low)
   - Attacker prerequisites (authenticated? network position?)
   - Proof-of-concept payload or curl command
2. Specifically look for: SQL injection, command injection, path
   traversal, SSRF, deserialization, XSS, auth bypass, IDOR,
   hard-coded secrets, insecure crypto, and race conditions.
3. The single most exploitable finding and a one-paragraph
   "how an attacker would chain this to RCE".
4. A unified diff (git-style) fix for the top 3 findings.

[paste vulnerable-webapp.py.txt]

✓ Self-check: A thorough audit of this file should yield at least 5 distinct vulnerabilities. If the AI finds fewer, ask "what else did you miss?" — it usually finds 1-2 more on a second pass.

Task 2.1 — Authentication and authorization review

Below is a Node.js/Express API. Focus your audit on:

1. Authentication flaws: weak JWT handling, missing signature
   verification, algorithm confusion (none/HS256/RS256), token
   replay, missing expiry checks.
2. Authorization flaws: missing ownership checks (IDOR), broken
   object-level access control, role checks done on client side,
   mass assignment.
3. Input validation: NoSQL injection, prototype pollution, regex DoS.
4. Async pitfalls: race conditions in check-then-act patterns,
   missing await on security-critical operations.
5. Dependency usage: any deprecated or known-vulnerable packages
   referenced by import.

For each finding output:
- File:line
- Vulnerability class
- Exploit scenario
- Minimal fix (show the corrected lines)

[paste vulnerable-api.js.txt]

✓ Self-check: Node APIs almost always have at least one IDOR and one JWT issue. You should be able to name both by the end of this exercise.

Task 3.1 — Memory safety and logic flaws

Below is a C authentication module. Audit for:

1. Memory safety bugs: buffer overflow (stack/heap), off-by-one,
   format string, use-after-free, double-free, integer
   overflow/underflow.
2. String handling pitfalls: unbounded strcpy/strcat/sprintf/gets,
   missing null terminators, assumptions about fixed sizes.
3. Authentication logic flaws: timing attacks on memcmp/strcmp,
   weak random number generation, predictable tokens, password
   stored in plaintext or with reversible encoding.
4. Integer handling: signed/unsigned confusion, truncation in
   size arguments.
5. For each finding, give:
   - Line number
   - Bug class (CWE)
   - Whether it is exploitable for code execution, info leak,
     or auth bypass
   - A patch (show before/after)

Rank findings by exploitability. Identify if any chain to RCE.

[paste legacy-auth.c.txt]

✓ Self-check: C code of this size usually has 2-4 memory safety issues. You should have at least one that the AI classifies as "exploitable for code execution."

Task 4.1 — Extract secrets and misconfigurations

Below is a YAML configuration file. Extract:

1. Every secret, credential, token, API key, or connection string
   (even if it looks like a "placeholder" — flag it anyway).
2. Every overly-permissive setting: debug modes on, wildcard CORS,
   allow-all CSP, TLS verification disabled, weak ciphers, default
   admin accounts.
3. Every service endpoint exposed to the internet that should not be.
4. Any reference to internal infrastructure that leaks topology
   (hostnames, private IPs, cluster names).
5. Any dangerous feature flag combinations (e.g., "dev_mode: true"
   in production, "allow_unauthenticated: true" on an admin API).

Output:
- Table of findings (key, value, risk, fix)
- The 3 changes with the largest blast-radius reduction

[paste config-leak.yaml.txt]

✓ Self-check: Config leaks usually contain at least one real-looking credential and one "debug: true" type setting. You should walk away with a credential you could try against a live endpoint and a misconfiguration that would change the attack surface.

Task 5.1 — Cross-artifact correlation

In a fresh AI conversation, paste the outputs of Exercises 1–4 and ask:

Here are four audit outputs for four files from the same
repository. Produce:

1. A consolidated findings table (all files, all vulns, deduped).
2. Any vulnerability that spans multiple files (e.g., a secret
   leaked in config that is used as an HMAC key in the Python app).
3. The top 5 findings ranked by CVSS 3.1 base score (estimate).
4. A 1-week remediation plan: what the dev team should fix in
   sprint 1, sprint 2, and backlog.
5. Three detection rules (Semgrep or CodeQL syntax) that would
   have caught the highest-severity issue in CI before merge.

Output as markdown, no more than 1200 words.

✓ Self-check: Your final report should identify at least one cross-file chain (e.g., "secret from config.yaml is used as a weak HMAC key in webapp.py, enabling signature forgery"). That cross-reference is the highest-value output of a code audit.