Bug BountyHunting

A bug bounty program is a standing invitation from an organization: "test our systems, within these rules, and we'll pay you for valid vulnerability reports." It flips the economics of security — instead of paying a fixed fee for a one-time pentest, a company pays per confirmed finding, drawing on thousands of researchers with different specialties instead of one consulting team. A Vulnerability Disclosure Program (VDP) is the unpaid cousin of this: "you can test us and report issues, we just won't pay a bounty" — these are where almost every hunter builds their first reputation.

1. Create accounts

   Sign up for free researcher accounts on HackerOne and Bugcrowd.

2. Read five real reports

   Open HackerOne's public Hacktivity feed and read five disclosed web-app reports. Note the structure: title, summary, steps to reproduce, impact.

3. Bookmark one VDP

   Find one Vulnerability Disclosure Program you could realistically test once you finish this workbook. Bookmark its policy page. Do not test it yet — that comes after Module 4.

1. Discover & verify privately

   Confirm the issue is real and reproducible before reporting — don't report a hunch.

2. Report through the official channel only

   Use the program's designated submission form or security@ address. Never DM employees or post on social media.

3. Wait for triage

   Don't re-test aggressively or escalate publicly while the team investigates. One clean follow-up question is fine; daily pings are not.

4. Cooperate during remediation

   Provide extra reproduction detail or a quick re-test if asked — this is what separates a one-off reporter from a trusted hunter.

5. Disclose publicly only with explicit permission

   And only after the agreed embargo period. Many programs never permit public write-ups — check before you assume.

1. Install Burp Suite Community Edition

   Download it from PortSwigger's site and install it for your OS. The free Community Edition covers everything in this workbook. On Kali, it's already there — just run burpsuite.

2. Route your browser through Burp

   Install the FoxyProxy extension and add a profile pointing to 127.0.0.1:8080 (Burp's default proxy listener). Switch it on only while testing.

3. Install Burp's CA certificate

   With the proxy on, visit http://burp in your browser, download cacert.der, and import it as a trusted root certificate so HTTPS traffic decrypts cleanly instead of throwing warnings.

4. Install Docker

   Install Docker Desktop if you don't already have it — this is how you'll run your practice target locally, on your own machine, fully under your control.

5. Pull and run OWASP Juice Shop

   Run the command below, then open http://localhost:3000. Juice Shop is an official OWASP project built specifically to be hacked — there is no target you could pick that is more legal to attack.

6. Confirm interception works

   Browse Juice Shop with the proxy switched on and watch requests appear live in Burp's HTTP history tab.

# pull & run OWASP Juice Shop locally — your practice target for Modules 2 & 3
docker run --rm -p 3000:3000 bkimminich/juice-shop

1. Install a recon tool

   Install subfinder or amass — both aggregate subdomains from dozens of public sources without sending traffic to the target itself.

2. Search Certificate Transparency logs

   Visit crt.sh and search a domain you own. Every TLS certificate ever issued for it is public record — and often reveals subdomains that were never meant to be found.

3. Run subfinder against your domain

   Aggregate findings from dozens of sources in one pass.

4. Cross-check with a Google dork

   Search site:yourdomain.com -www to surface indexed subdomains and pages search engines have crawled.

5. Start a recon notes file

   Target, subdomain list, dates, notes. Build this habit now — every future engagement starts the same way.

# passive subdomain enumeration
subfinder -d yourdomain.com -silent

# certificate-transparency lookup via crt.sh
curl -s "https://crt.sh/?q=%25.yourdomain.com&output=json" | jq -r '.[].name_value' | sort -u

1. Read response headers

   Use Burp's HTTP history (or curl -I) to inspect Server and X-Powered-By headers on your local Juice Shop instance.

2. Install Wappalyzer

   Browse Juice Shop with the extension active and note the detected stack — frontend framework, backend hints, analytics, everything.

3. Trigger a verbose error

   Request a malformed or nonexistent route and see whether the response leaks a stack trace, file path, or framework version.

4. Check old JS bundles

   On a domain you own, search the Wayback Machine for old JavaScript bundle names or API paths that might still be live but no longer linked anywhere.

# quick header fingerprint
curl -I http://localhost:3000

1. Install ffuf

   Or gobuster — either works for this lab.

2. Grab a wordlist

   SecLists' common.txt is a solid, widely-used starting point.

3. Run content discovery against Juice Shop

   Fuzz for real paths against your local instance only.

4. Investigate every non-404

   Open each 200/301/403 manually and note what it actually is.

5. Map the REST API directly

   Juice Shop exposes /rest/ and /api/ routes. Browse normally with Burp's proxy on, then review the HTTP history to map real calls the app makes.

# directory & endpoint discovery against your local Juice Shop instance
ffuf -w /path/to/common.txt -u http://localhost:3000/FUZZ -mc 200,301,302,403

1. Log in and browse normally

   Visit your account, basket, and order history while Burp's proxy captures every request.

2. Find ID-bearing requests

   In Burp's HTTP history, look for calls like /rest/basket/6 or /rest/user/whoami that reference a numeric or predictable ID.

3. Tamper with the ID

   Send the request to Repeater and change the ID to a neighboring value. Resend it — do you get back someone else's data?

4. Test function-level access control

   As a normal user, try navigating directly to an admin-only route (e.g. Juice Shop's /#/administration). Does it load without checking your role?

5. Document the exact exposure

   Which ID, which endpoint, what data came back that shouldn't have. This becomes your report in Module 4.

1. Capture a normal login

   Submit a regular (failing) login attempt and capture the request in Burp.

2. Send it to Repeater

   Replace the email field with the classic bypass payload below.

3. Observe the response

   Did it log you in without valid credentials — often as the very first account in the database?

4. Confirm impact

   Check the account email shown post-login to prove whose account you accessed.

-- classic SQLi authentication-bypass payload, entered in the email field
' OR 1=1--

1. Reflected XSS

   Juice Shop's search bar reflects your input straight into the page. Try the payload below in the search field.

2. Stored XSS

   Find a field that stores input for other users to view later — a product review or comment. Submit the payload there and reload as a different session.

3. DOM-based XSS

   Start a free "DOM XSS" lab on PortSwigger Web Security Academy — purpose-built for client-side sinks like innerHTML and document.write.

4. Always prove it cleanly

   Use alert(document.domain) as your proof. It's the industry-standard, non-destructive way to show you control execution.

// non-destructive proof-of-execution payload — industry standard for reports
<script>alert(document.domain)</script>

1. Start a CSRF lab

   Open PortSwigger Academy's "CSRF vulnerability with no defenses" lab (free).

2. Build a minimal auto-submit proof-of-concept (PoC) page

   An HTML form that fires a state-changing request on page load — see the template below.

3. Host and trigger it

   Follow the lab's instructions to deliver it to the simulated victim and confirm the account state changes.

1. Start a free SSRF lab

   Find a feature that fetches a URL on the server's behalf — a "check stock at this URL" type feature is the classic Academy example.

2. Redirect it internally

   Supply an internal address instead of the expected external one.

3. Confirm impact

   Did the app return internal content it shouldn't have access to?

<!-- minimal CSRF PoC: auto-submitting form -->
<form action="https://lab-target/email/change" method="POST" id="f">
  <input type="hidden" name="email" value="attacker@evil.com">
</form>
<script>document.getElementById('f').submit()</script>

// SSRF: point a "fetch URL" feature at an internal address
http://localhost:8080/admin

1. Check for exposed version control

   Request /.git/config. A 200 response can mean the entire repo history is downloadable.

2. Try default/test credentials

   Juice Shop deliberately ships some weak accounts — try a few common combinations through the login form, mindful of rate limits.

3. Trigger a debug page

   Send a deliberately malformed request and see whether a stack trace renders instead of a clean error.

4. Check security headers

   Look for missing Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security.

# check for an exposed .git directory
curl -I http://localhost:3000/.git/config

# check security headers
curl -I http://localhost:3000

1. Test the password reset flow

   Request a reset and inspect the token in Burp — is it predictable, reusable, or missing an expiration?

2. Decode the session token / JWT

   Use Burp's built-in JWT tab or jwt.io to read the header and payload — what claims does it carry, and how is it signed?

3. Try a known JWT attack

   Run a free PortSwigger JWT lab and test whether the server actually verifies the signature, or accepts an alg: none token.

4. Check session reuse after logout

   Log out, then replay the old token against a protected endpoint — does the server still accept it?

// decode a JWT's header & payload (no key needed for this part)
echo "<jwt-token>" | cut -d. -f1,2 | base64 -d

1. Test price/quantity tampering

   Intercept a basket request in Repeater and alter the price or set quantity to a negative number before checkout.

2. Test coupon abuse

   Try reusing a one-time coupon code multiple times, or stacking several at once.

3. Test for a race condition

   Use Burp's parallel request sending (or Turbo Intruder) to fire the same redeem/discount request several times simultaneously.

4. Test workflow-step skipping

   Try jumping straight to an "order confirmation" style URL without completing the step that's supposed to come before it.

// example: tampered basket request, quantity changed to negative
{"ProductId": 5, "BasketId": 12, "quantity": -10}

1. Test file type validation

   On Juice Shop's profile picture or complaint upload, try a file with a mismatched extension/content-type — e.g. an SVG containing a script, renamed with an image extension.

2. Test path handling

   Try a filename containing path traversal characters and see how the server handles it.

3. Test API authorization with Postman

   Replay each API call with no auth token, an expired token, and another user's token — this is BOLA (Broken Object Level Authorization), the API version of IDOR.

4. Test API rate limiting

   Send the same request rapidly and check whether you ever get a 429 throttling response.

// path traversal attempt in an upload filename
../../../etc/passwd.jpg

1. Recon (≈15 min)

   Re-run fingerprinting and endpoint discovery fresh. List every API route you can find.

2. Access control (≈20 min)

   Systematically test every ID-bearing endpoint you found for IDOR/BOLA.

3. Injection (≈20 min)

   Test every input field — search, login, registration, contact/feedback — for SQLi and XSS.

4. Logic & workflow (≈20 min)

   Test checkout for price/quantity tampering, coupon reuse, and step-skipping.

5. Configuration & auth (≈15 min)

   Check headers, exposed files, the password reset flow, and session handling.

6. Write-up (≈20 min)

   Draft a one-paragraph summary and reproduction steps for your single best finding.

1. Pick your strongest capstone finding

   The clearest, most reliably reproducible one — not necessarily the scariest-sounding.

2. Write a precise title

   Pattern: "[Vulnerability class] in [location] allows [impact]" — e.g. "IDOR in /rest/basket/:id allows viewing other users' basket contents."

3. Write numbered reproduction steps

   Exactly as you'd hand them to a stranger who has never opened the app before.

4. Attach proof

   A screenshot of the request/response pair, or a short screen recording — visual evidence, not just a description.

5. State impact precisely

   "An attacker can view any other user's basket contents by incrementing the basket ID" — not "this could lead to a full data breach."

6. Estimate severity

   Use CVSS (the Common Vulnerability Scoring System) if the program requires it, or its plain Low/Medium/High/Critical scale otherwise.

1. Submit through the official channel only

   Never email an employee directly or post on social media.

2. Respond promptly and politely

   To any triager follow-up questions.

3. Accept duplicates and rejections without argument

   One calm clarifying question is fine; repeated pushback damages your reputation.

4. Track your own stats

   Submissions, response time, acceptance rate — over time this becomes your case for private program invites.

1. Week 1

   Re-run Modules 0–1 against a second self-owned target. Join Bugcrowd University's free courses for the categories you felt weakest in.

2. Week 2

   Clear 10 more PortSwigger Academy labs in categories you haven't tried yet — insecure deserialization, NoSQL injection, GraphQL flaws.

3. Week 3

   Pick the VDP you bookmarked back in Lab 0.1. Read its policy twice. Do your first authorized recon pass under its actual scope.

4. Week 4

   Submit your first real report on that program, using the format from Lab 4.1. Whatever the outcome, log what you'd do differently.

1. Start a free XXE lab

   PortSwigger Academy's "Exploiting XXE to retrieve files" is the standard starting point.

2. Find an XML-consuming endpoint

   Stock checkers, file import/export, and SOAP-based features are the classic locations.

3. Submit a DOCTYPE entity payload

   Define an external entity pointing at a local file, then reference it in the document body.

4. Check for in-band leakage

   Does the file's content come back directly in the response?

5. Try blind (out-of-band) XXE

   If nothing comes back directly, point the entity at a server you control (e.g. Burp Collaborator) and watch for a callback.

<!-- XXE payload to read a local file -->
<?xml version="1.0"?>
<!DOCTYPE data [<!ENTITY xxe SYSTEM "file:///etc/hostname">]>
<data>&xxe;</data>

1. Start a PortSwigger SSTI lab

   Free, purpose-built for this exact bug class.

2. Identify a candidate input

   Anything reflected back unescaped into a rendered page — a "name" field used in a personalized greeting is the classic case.

3. Send a generic math probe

   The payloads below are distinctive across the major template engine families.

4. Fingerprint the engine

   Whichever probe evaluates tells you which engine — and therefore which exploitation path — you're dealing with.

5. Escalate inside the lab only

   Once fingerprinted, follow the lab's own path from "it evaluates math" toward full code execution.

// generic SSTI probes — distinctive across engines
{{7*7}}        // Jinja2 / Twig: renders 49 if vulnerable
${7*7}         // FreeMarker / Velocity-style: renders 49 if vulnerable
<%= 7*7 %>     // ERB / similar engines: renders 49 if vulnerable

1. Start a PortSwigger deserialization lab

   Free, with a session-handling mechanic built around this exact bug.

2. Find a suspicious cookie or parameter

   Look for base64 blobs, Java's rO0 magic bytes, or PHP's O:8:"ClassName" pattern.

3. Decode it

   Inspect the underlying object structure once decoded.

4. Modify a property

   Change a role or admin flag, then re-encode it in the original format.

5. Resend and check trust

   Does the server trust your modified value without re-validating it?

# PHP serialized object — note the O:length:"ClassName" pattern
O:4:"User":2:{s:8:"username";s:5:"alice";s:5:"admin";b:0;}

# Java serialized objects start with this magic byte sequence (base64)
rO0AB...

1. Start a PortSwigger NoSQL injection lab

   Free, built specifically around MongoDB-style query injection.

2. Test the login form with an operator payload

   Instead of a SQL-style string, send an operator object in place of a value.

3. Try the form-encoded variant

   If the app expects form data rather than JSON, the operator syntax changes slightly — see below.

4. Try a $where JavaScript payload

   Some MongoDB deployments allow arbitrary JavaScript evaluation inside queries.

5. Confirm the bypass

   Same proof standard as SQLi — are you logged in without a valid password?

// NoSQL auth bypass: send password as an operator object instead of a string
{"username": "admin", "password": {"$ne": null}}

// classic operator-based bypass in a URL-encoded form field
username=admin&password[$ne]=1

1. Find the GraphQL endpoint

   Commonly /graphql, /api/graphql, or /v1/graphql.

2. Check whether introspection is enabled

   It documents the entire schema for you, including hidden fields and mutations.

3. Test an ID-bearing query for BOLA

   Exactly like Lab 3.2's API authorization testing, just expressed in GraphQL syntax.

4. Test query batching

   GraphQL allows multiple queries in a single request — check whether this lets you bypass a per-request rate limit.

5. Test for excessive data exposure

   Request every field a query allows and see if it returns more than the UI ever displays.

# introspection query — dumps the entire schema if enabled
{ __schema { types { name fields { name } } } }

1. Revisit your Module 1 subdomain list

   On a domain you own, check each subdomain's DNS record for a CNAME pointing to an external service.

2. Visit each candidate subdomain

   Look for a "no such bucket/app" style error instead of real content — a sign the underlying resource was deleted but the DNS record never was.

3. Confirm against a known fingerprint list

   Public "can-i-take-over-xyz" style references document the exact error text each cloud provider returns for an unclaimed resource.

4. On your own infrastructure only

   If confirmed, you could register the resource yourself to verify the takeover — then immediately release it and fix the DNS record.

1. Start a PortSwigger request smuggling lab

   Free, and the safest place to ever attempt this technique.

2. Send conflicting length headers

   The classic CL.TE desync sends both Content-Length and Transfer-Encoding, disagreeing about where the request ends.

3. Observe the desync

   Does the front-end and back-end server disagree, letting a hidden second request "ride along"?

4. Confirm impact via the lab's indicator

   Usually capturing another (simulated) user's request.

-- DNS check: does this subdomain's CNAME point somewhere now abandoned?
dig CNAME forgotten.yourdomain.com

// classic CL.TE request smuggling headers — practice inside a lab only
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

1. Install Android Studio or platform-tools

   Gets you adb and an emulator — or use a personal Android device with USB debugging enabled.

2. Install MobSF

   Free, automated static and dynamic analysis for APKs, via Docker.

3. Install Frida and Objection

   Your dynamic instrumentation toolkit for later labs in this module.

4. Download practice apps

   OWASP MASTG Crackmes, DIVA — Damn Insecure and Vulnerable App (github.com/payatu/diva-android), and InsecureBankv2 (github.com/dineshshetty/Android-InsecureBankv2) — all free, open-source, built specifically to be hacked.

5. Install one and confirm it launches

   Side-load a practice APK onto your emulator/device via adb.

# pull MobSF via Docker
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

# install Frida + Objection for dynamic instrumentation
pip install frida-tools objection

# install a practice APK on a connected device/emulator
adb install diva-beta.apk

1. Decompile with jadx

   Get readable Java/Kotlin-like source from the compiled bytecode.

2. Unpack with apktool

   Get AndroidManifest.xml and resources in near-original form.

3. Read the manifest

   Look for exported="true" on Activities, Services, or Broadcast Receivers — these can potentially be launched by any other app on the device.

4. Grep the decompiled source for secrets

   API keys, hardcoded credentials, encryption keys committed straight into the code.

5. Run MobSF for a first pass

   Then compare its automated findings against what you found manually.

# decompile to readable source
jadx -d output_folder diva-beta.apk

# unpack manifest & resources
apktool d diva-beta.apk

# grep for common hardcoded-secret patterns
grep -rniE "api[_-]?key|secret|password\s*=" output_folder/

1. Use the app normally

   Log in and enter sensitive test data — never real personal information.

2. Pull the app's data directory

   Requires a rooted device/emulator — or use adb backup on a non-rooted one.

3. Inspect SharedPreferences

   Look through the XML files for plaintext credentials or tokens.

4. Inspect any SQLite databases

   Open with a SQLite browser and search sensitive columns.

5. Check external/shared storage

   Data written there is readable by any other app with storage permission.

# pull the app's private data directory (rooted device/emulator)
adb shell "run-as jakhar.aseem.diva cat /data/data/jakhar.aseem.diva/shared_prefs/diva_prefs.xml"

# or, on a non-rooted device, use a full backup
adb backup -f backup.ab jakhar.aseem.diva

1. Set the device's Wi-Fi proxy

   Point it at Burp listening on your machine.

2. Install Burp's CA certificate

   As a trusted user certificate (or system, on rooted devices).

3. Browse the app and check Burp

   Requests should appear in HTTP history, exactly like a web app.

4. Notice if traffic doesn't appear

   A connection error or missing requests usually means certificate pinning — the app only trusts its own hardcoded certificate.

5. Bypass pinning with Objection

   Attach to the running app and disable the pinning check at runtime, with no APK modification needed.

6. Confirm traffic now appears

   Retry the same action and check Burp's HTTP history again.

# attach Objection to a running app and bypass SSL pinning
objection -g jakhar.aseem.diva explore
# inside the objection shell:
android sslpinning disable

1. List exported components

   From your Lab 6.2 manifest review.

2. Launch an exported Activity directly

   Via adb, bypassing the app's normal login/navigation flow.

3. Test deep links

   If the app registers a custom URL scheme, craft a link that jumps straight to a sensitive screen.

4. Test exported Broadcast Receivers

   Send a crafted broadcast and observe whether the app reacts to it from an untrusted source.

5. Document the exact path

   Which component, which intent, what unauthorized action resulted.

# launch an exported activity directly, skipping login
# (use the real package/activity names from your own Lab 6.2 manifest review)
adb shell am start -n com.android.insecurebankv2/.PostLogin

# trigger a custom URL scheme deep link
adb shell am start -a android.intent.action.VIEW -d "divabank://transfer?amount=1000"

The core shift: black-box, you guess where a bug might be. White-box, you can grep for it directly — then confirm it the same way you always have.

1. Clone Juice Shop's own GitHub repo

   At github.com/juice-shop/juice-shop — the exact source of the app you've been testing black-box since Module 0.

2. Find the code behind a bug you already found

   E.g. the SQL injection login bypass from Lab 2.2.

3. Compare what reading taught you vs. testing blind

   Note specifically what the source revealed that probing alone never would have.

1. Grep for string-concatenated SQL

   A classic injection pattern, in your cloned Juice Shop repo.

2. Grep for innerHTML / eval / unsanitized template literals

   Classic XSS or code-injection sinks.

3. Grep for child_process.exec-style calls

   Command injection candidates if user input reaches them.

4. Trace each hit backward

   Does user-controlled input actually reach this sink, or is it hardcoded/sanitized?

5. Confirm one hit live

   Against your running Juice Shop instance — full circle from source to working proof.

# grep for classic vulnerable patterns across a cloned repo
grep -rn "innerHTML" --include=*.ts src/
grep -rn "child_process" --include=*.js routes/
grep -rnE "SELECT .* \+ |query\(.*\+" --include=*.ts src/

1. Install Semgrep

   A fast, rule-based static analysis tool with public security rulesets.

2. Run a public ruleset against your cloned repo

   Covers hundreds of known vulnerable patterns in seconds.

3. Triage the output

   Separate genuine findings from noise — the same instinct as Lab 7.2's manual grep, just at scale.

4. Install gitleaks or trufflehog

   Tools built specifically to scan full commit history for secrets.

5. Scan the full history, not just current files

   A secret deleted in a later commit is still recoverable from history unless the repo was rewritten.

# run Semgrep's public security ruleset against a cloned repo
semgrep --config p/security-audit .

# scan full git history for leaked secrets, not just current files
gitleaks detect --source . --log-opts="--all"

1. Run a dependency audit

   Against the project's manifest file.

2. Review each flagged package

   Is the vulnerable code path actually reachable by the app, or just present but unused?

3. Check the advisory for the fixed version

   This becomes your report's remediation advice.

4. Treat it as a complete finding

   "You're running version X of library Y with known CVE-Z" is a valid, reportable bug on its own.

# Node.js projects
npm audit

# Python projects
pip-audit

1. Start a simple write-up home

   A personal site, a blogging platform, or even a structured GitHub repo of markdown write-ups — the platform matters far less than consistency.

2. Write up every lab capstone and CTF you complete

   Using this workbook's report format from Module 4. These are 100% safe to publish — your own work, on sanctioned practice targets.

3. Never publish a real finding without explicit permission

   Not even after it's fixed. Check the program's disclosure policy every single time.

4. Keep every write-up to one structure

   Target/lab name, vulnerability class, your approach, the fix.

5. Link it from your platform profile

   This is exactly what triagers and program managers check before private invites.

1. Pick a platform matched to your level

   picoCTF for fundamentals, TryHackMe or HackTheBox for web-focused rooms, live competitions for speed under pressure.

2. Revisit your Lab 3.3 capstone scorecard

   Identify your weakest category.

3. Search specifically for that category

   Don't just play whatever's trending — target the gap.

4. Time-box each attempt

   Then read the official write-up after, win or lose — that's often where the real learning happens.

5. Keep a running log

   Challenge, category, solved/unsolved, what you'd do differently.

1. Decide your actual goal first

   A job that requires a credential on paper, or pure bounty income, which cares only about results.

2. If bounty income is the goal

   The free path — this workbook, PortSwigger Academy, CTFs, and real programs — is sufficient on its own.

3. If a job is the goal

   Check three real job listings you'd actually apply to and match the certification to what they ask for — don't guess.

1. Join one community properly

   Rather than five superficially — a specific Discord server, r/bugbounty, or a local security meetup.

2. Follow hunters in your weak categories

   Engage with a handful who write specifically about the areas your capstone scorecard flagged.

3. Set a quarterly review, not a daily one

   Track submissions, acceptance rate, and your best-performing category, then bias next quarter toward it.

4. Attend one in-person event a year if possible

   A local BSides conference is inexpensive and the single best way to turn online contacts into real opportunities.

5. Revisit Module 0's ethics rules yearly

   The fundamentals don't change, but it's easy to drift as confidence grows.