Introduction to penetration testing: a workshop for software security engineers

Who this workshop is for

This outline is built for a team of software security engineers who write and review secure code every day but have never run an offensive test themselves. The goal is not to turn the team into professional testers in an afternoon. It is to build a working mental model for how a tester reads traffic, tampers with a request, and reasons about why a server accepted something it should have rejected, so the same instincts sharpen how they review pull requests and design authorization checks.

The track is twelve missions long, sequenced so a beginner can walk it top to bottom: three proxy fundamentals missions, four authorization bypass missions, four injection missions, and one closing mission on writing a finding up. Every scenario runs against a fictional training app and is framed defensively throughout: what the server did wrong, what the correct control is, and how to explain the finding in a review.

What a proxy does, and why every mission starts there

A proxy sits between the browser and the server, so it captures the literal bytes of every request that leaves the client and every response that comes back, before the browser renders anything and before any client-side JavaScript runs. That single fact is the foundation the whole workshop is built on: once a request can be sent through the proxy directly, any control that only lives in the browser, a disabled button, a format check in JavaScript, a hidden form field, offers no real protection at all.

Two proxy skills carry the rest of the track. Reading traffic means separating a request into its method, path, headers, cookies, and body, then reading the response's status and body the same way, so the parameter that actually controls the server's behavior is easy to spot. Repeating traffic means resending a captured request with one value changed and comparing the two responses, which is how a tester (or a reviewer) tests whether a parameter is meaningfully checked or merely read.

The twelve missions in order

The missions live in the platform's mission library across three categories (Web Application, Exploits, and Secure Code Review), so their internal ordering numbers differ by category. This is the order the workshop is meant to run in.

• 1. Reading an Intercepted Request: read a captured request and response and identify the parameter that selects which record the server returns.
• 2. Repeating a Request with a Changed Value: resend a captured request with one parameter edited and identify the response field that proves the data changed.
• 3. What the Proxy Proves About Client-Side Controls: compare a browser-originated request to one sent straight through the proxy and name the control that offered zero real protection.
• 4. IDOR on a Numeric Invoice Reference: change a sequential object reference and name the vulnerability class when the server never checks ownership.
• 5. Role Tampering via a Client-Supplied Field: edit a role field the client should never be able to set and explain what the acceptance reveals about the server's trust model.
• 6. Forced Browsing to an Unchecked Admin Endpoint: request a hidden admin URL directly and name the missing server-side authorization check.
• 7. A Bearer Token the Server Never Verifies: compare a normal JWT to one with its algorithm set to none and name the control the server must always run before trusting a claim.
• 8. SQL Injection through String Concatenation: send a crafted search term and name the fix for how the query is built.
• 9. Command Injection via an Unsanitized Argument: chain a second command through a filename argument and name the fix for how the command is invoked.
• 10. SSRF through a URL Parameter: point a server-side fetch at an internal address and name the missing destination control.
• 11. NoSQL Injection via Query Operators: replace a password value with a query operator and name the vulnerability class and fix together.
• 12. Writing Up a Finding: Severity and Remediation: given the evidence from a finding, choose the accurate severity and the remediation that fixes the cause rather than the symptom.

Authentication and authorization are not the same check

Authentication answers who is making this request, usually proven by a session cookie or a bearer token. Authorization answers what that specific, authenticated identity is allowed to do or see. Every authorization bypass mission in this track (missions 4 through 7) uses a request that is fully authenticated, a real session cookie, a signed token header, and shows that authentication alone tells a server nothing about whether that identity should reach a particular record or a particular route.

The practical habit this builds: whenever a request handler reads a session or a token, ask a second, separate question before any privileged action runs, whether that identity is authorized for the specific object or action being requested. A missing authentication check produces an anonymous attacker. A missing authorization check produces an attacker who is fully logged in as themselves and simply asks for something that was never checked against who they are.

How the injection classes relate to each other

SQL injection, command injection, SSRF, and NoSQL injection look like four unrelated bugs, but the track sequences them together because they share one underlying pattern: untrusted input reaches an interpreter, a SQL engine, a shell, an HTTP client, a query filter, without the interpreter ever being told which parts of the combined string or object are trusted syntax and which parts are attacker-controlled data.

SQL injection and command injection both come from building a command as a single string through concatenation, so a quote or a semicolon in the input is read as syntax instead of as a literal value; the fix in both cases is to stop building that string by hand, a parameterized query in one case and an argument array with no shell in the other. SSRF is the same trust failure applied to an HTTP client instead of a query language: the server treats a user-supplied URL as a safe destination and fetches it on the caller's behalf. NoSQL injection is the same failure applied to a query object instead of a query string: a field the application assumed would always be a string can instead be a query operator, changing what the filter matches.

Running this as a live workshop

A single session works well as three blocks with a short break between each. Run the three proxy fundamentals missions together as a live, narrated group walkthrough, since the whole team needs the same mental model of reading and repeating traffic before anything else makes sense. Split into pairs for the authorization bypass and injection missions, and rotate who drives the proxy tool inside each pair so both people get hands-on practice rather than one person clicking while the other watches.

Close as a full group on the reporting mission. Have each pair state the severity and remediation they would write for the sample finding out loud before revealing the walkthrough, then compare reasoning across pairs. The disagreements are usually the most useful part of the session, since they surface how differently engineers weigh scope, sensitivity, and effort when a finding has not been handed to them with a severity already attached.

Glossary

A short reference for terms used throughout the track.

• Proxy: a tool positioned between the browser and the server that captures, and optionally edits, every request and response passing through it.
• Intercept: pausing a request in the proxy before it reaches the server, so it can be inspected or edited first.
• Repeater: a proxy feature for resending a captured request with values changed, without going back through the browser.
• IDOR (insecure direct object reference): a request parameter that selects a specific record with no check that the caller is allowed to access that record.
• Forced browsing: requesting a URL directly rather than through the interface's normal navigation, often used to reach a route the interface hides but the server never protects.
• SSRF (server-side request forgery): tricking a server into making an outbound request, often to an internal address, on the attacker's behalf.
• JWT alg none: a token attack where the header's declared algorithm is used to skip signature verification entirely, so the payload's claims are trusted unverified.
• Severity: a rating of how much damage a finding could cause if left unfixed, weighed on scope, sensitivity, and the effort required to exploit it.
• Remediation: the specific control change that removes a finding's root cause, as distinct from a change that only masks its symptom.