WEB-200 / OSWA

DETECT

• Input reappears in HTML, attributes, script blocks, URLs, DOM nodes, templates, previews, logs, messages, profiles, or administrator queues.
• The browser changes the DOM after load using location, hash, query, postMessage, localStorage, or API data.
• Stored content is later viewed by a higher-privileged or emulated user.

TEST

1. Locate the exact reflection or storage point and determine whether rendering is server-side or client-side.
2. Identify the context: HTML text, quoted/unquoted attribute, JavaScript string, URL, CSS, or DOM sink.
3. Use a harmless marker, then a context-appropriate execution proof. Avoid assuming a popup is the final objective.
4. Check encoding, sanitization, CSP, cookie HttpOnly/SameSite flags, and whether same-origin requests remain possible.
5. For an emulated administrator, host the smallest reliable callback payload and confirm the visit.
6. Use same-origin access or requests to reach the administrator area, then capture local.txt with the required browser/proxy evidence.

CHAIN

• Read non-HttpOnly cookies or browser storage only when the application actually keeps useful secrets there.
• If cookies are protected, use JavaScript running in the victim origin to perform administrative actions or read same-origin responses.
• Keep the callback and exfiltration path observable in your notes; distinguish the first hit from successful authenticated action.

FUCKUPS

• Testing only a generic script tag without identifying the output context.
• Ignoring DOM/client-side flows because the raw response does not contain the payload.
• Treating JavaScript execution as completion without obtaining the requested administrator objective.
• Using a listener address that the target cannot reach or serving a payload with the wrong MIME type.

EVIDENCE

• Vulnerable request and rendered response
• Exact context and payload
• Callback or administrator visit
• Authenticated administrator view
• local.txt browser and proxy screenshots

TOOLS

• Burp/ZAP HTTP history and resend
• Browser developer tools
• Python HTTP server or equivalent callback host
• Access log and listener

DETECT

• State-changing requests rely only on cookies and lack an unpredictable request-bound token.
• Origin is reflected into Access-Control-Allow-Origin or weakly checked by prefix/suffix.
• Credentialed cross-origin responses are permitted to an attacker-controlled origin.
• A privileged user predictably visits attacker-controlled content.

TEST

1. Record method, content type, cookies, CSRF token, Origin/Referer behavior, redirects, and response requirements.
2. Remove or alter each anti-CSRF control independently and verify whether the state change still succeeds.
3. Determine whether a simple form is sufficient or JavaScript/CORS is required.
4. For CORS, vary Origin using exact attacker origins, null, scheme/port changes, subdomains, prefixes, and suffixes.
5. Confirm both browser acceptance and credential inclusion; permissive response headers alone may not be exploitable.
6. Chain the cross-origin primitive into an administrative read or state change that exposes the exam objective.

CHAIN

• Use CSRF for blind privileged state changes such as adding an account, changing an email, or modifying content.
• Use exploitable credentialed CORS when the attacker origin can read sensitive responses.
• Combine stored XSS or an emulated-user visit with the cross-origin action when direct delivery is required.

FUCKUPS

• Calling a wildcard ACAO exploitable when credentials are required.
• Ignoring SameSite behavior and top-level navigation differences.
• Testing with a request tool instead of confirming actual browser enforcement.
• Failing to verify the privileged side effect.

EVIDENCE

• Original privileged request
• Removed/bypassed control
• Browser-deliverable PoC
• Privileged side effect or readable response
• Administrator objective

TOOLS

• Burp/ZAP Repeater or Requester
• Browser console and network panel
• Local HTML PoC
• HTTP callback server

DETECT

• Quotes, parentheses, comments, type changes, sorting expressions, or boolean conditions change the response.
• Database error text, column names, SQL fragments, or consistent timing differences appear.
• Search, filter, sort, ID, login, report, or JSON parameters influence database-backed content.

TEST

1. Establish a stable baseline and identify whether the value is numeric, string, list, identifier, ORDER BY, or function input.
2. Balance quotes and parentheses; test true/false conditions and native comments without combining many mutations.
3. Identify MySQL, PostgreSQL, MSSQL, or Oracle through errors, functions, concatenation, timing, and metadata behavior.
4. Count columns with ORDER BY or UNION NULLs and identify visible compatible columns.
5. Enumerate current database/user, schemas, tables, columns, and only the data required for the objective.
6. Evaluate stacked queries, file read/write, database-specific command execution, or web-shell placement.
7. After manual confirmation, use SQLMap narrowly with a saved request and known parameter when it reduces repetitive work.

CHAIN

• Authentication bypass or administrative credential recovery may lead directly to local.txt.
• File read can reveal configuration, source, credentials, or writable web roots.
• File write, stacked queries, MSSQL execution features, or database extensions may lead to a shell and proof.txt.

FUCKUPS

• Launching SQLMap before understanding the request, parameter, session, CSRF behavior, or query context.
• Using a UNION with the wrong column count or incompatible data types and concluding the input is safe.
• Assuming all database dialects share comments, concatenation, metadata tables, or file capabilities.
• Dumping everything instead of pursuing the shortest objective path.

EVIDENCE

• True/false or error confirmation
• Dialect identification
• Working enumeration query
• Administrative or RCE transition
• Original-location proof screenshot

TOOLS

• Burp/ZAP manual resend
• Wfuzz or proxy fuzzer
• SQLMap after confirmation
• Dialect reference and UNION workbench

DETECT

• Parameters resemble file, page, template, language, theme, download, document, image, path, or directory names.
• Changing a value produces file-not-found, absolute-path, include, or directory-listing errors.
• A route returns server files or accepts a filename independent of an object authorization check.

TEST

1. Determine the expected base directory, filename, extension, prefix, suffix, and whether the application accepts absolute paths.
2. Test a known application file before distant operating-system paths so success is measurable.
3. Increase traversal depth methodically and test Unix/Windows separators appropriate to the target.
4. Evaluate URL encoding, double encoding, mixed separators, normalized dot segments, and validated-versus-used path differences.
5. Test whether an enforced suffix can be bypassed or whether the desired file already matches it.
6. Use controlled path wordlists only after learning the path grammar.
7. Read configuration or source material that advances authentication, command execution, or the requested proof.

CHAIN

• Application source reveals hidden routes, secrets, database access, templates, and command construction.
• Configuration and environment files may provide administrator credentials or internal service locations.
• Log or file inclusion may become code execution only when the application actually interprets the included content.

FUCKUPS

• Using a fixed traversal depth without learning the working directory.
• Ignoring URL decoding performed by a proxy, framework, or front-end before application validation.
• Confusing an application-level download authorization issue with filesystem traversal.
• Claiming file access from an error without retrieving controlled or known content.

EVIDENCE

• Baseline file request
• Working traversal grammar
• Known file contents
• Sensitive file that advances the chain
• Resulting administrator or server proof

TOOLS

• Burp/ZAP resend and decoder
• Wfuzz path fuzzing
• curl --path-as-is
• SecLists traversal lists used selectively

DETECT

• Endpoints accept XML, SOAP, SVG, office-like documents, imports, feeds, or content-type changes from JSON/form data.
• Malformed XML returns parser names, line numbers, entity errors, or expanded values.
• An import or conversion feature processes user-supplied structured documents.

TEST

1. Preserve a valid baseline document and modify the smallest possible element.
2. Confirm entity expansion with a harmless internal entity before referencing local files or URLs.
3. Try in-band external entities when response data is reflected.
4. Use error-based or external-DTD techniques when direct output is unavailable.
5. Use a controlled callback to confirm blind retrieval and record DNS versus HTTP behavior.
6. Select files compatible with the parser and output context; binary or markup-heavy files may fail.
7. Chain file or network access to credentials, internal services, administrator access, or server execution.

CHAIN

• Read application configuration, source, environment, and service credentials.
• Reach localhost or internal HTTP services using external entity URLs.
• Use out-of-band retrieval when the parser can connect outward but the response is not reflected.

FUCKUPS

• Breaking the document before reaching the parser.
• Assuming all parsers allow DOCTYPE, external general entities, parameter entities, and network requests equally.
• Using a file whose characters make the XML response invalid.
• Recording a callback without proving which request caused it.

EVIDENCE

• Valid baseline XML
• Internal expansion proof
• External file or callback proof
• Parser-specific payload
• Chain to objective

TOOLS

• Burp/ZAP content-type and body editing
• Python HTTP server
• Listener logs
• XML syntax reference

DETECT

• Arithmetic or expression syntax evaluates inside generated pages, emails, previews, names, themes, CMS content, or translation features.
• Errors mention template syntax, filters, classes, engine names, undefined variables, or sandbox restrictions.
• The same value renders differently in preview and saved output.

TEST

1. Use harmless arithmetic probes in multiple syntaxes and compare evaluated output with literal reflection.
2. Fingerprint Twig, Jinja, FreeMarker, Pug, Mustache, or Handlebars through syntax collisions and error language.
3. Map the rendering context, available variables, filters, functions, objects, and sandbox behavior.
4. Consult the exact engine/version documentation and construct the shortest engine-specific path.
5. Confirm low-impact server-side access before invoking operating-system commands.
6. Select a shell payload compatible with the server runtime and network reachability.
7. Record each object or function transition; template-engine payloads are brittle without context.

CHAIN

• Read configuration or environment values exposed to the template.
• Reach language runtime objects, process APIs, or command helpers when the engine exposes them.
• Write a web shell or obtain a callback shell, then capture proof.txt.

FUCKUPS

• Assuming {{7*7}} uniquely identifies Jinja or Twig.
• Using payloads from a different engine, version, sandbox, or framework integration.
• Confusing client-side templates with server-side evaluation.
• Skipping intermediate confirmation and debugging only the final reverse shell.

EVIDENCE

• Literal-versus-evaluated proof
• Engine fingerprint
• Accessible object/function
• Command output or callback
• proof.txt from original location

TOOLS

• Burp/ZAP resend
• SSTI fingerprint workbench
• Tplmap after manual confirmation
• Engine documentation

DETECT

• Features invoke ping, DNS, archive, image, document, backup, diagnostic, build, converter, or administrative utilities.
• Separators, substitution, quoting, or delay commands change output or timing.
• Errors expose shell syntax, executable paths, command arguments, or process failures.

TEST

1. Determine operating system, shell, command location, argument position, quoting, normalization, and allowed characters.
2. Try one appropriate separator or substitution construct with a harmless command.
3. When output is hidden, confirm with deterministic delay and then a controlled callback.
4. Enumerate identity, working directory, environment, available interpreters, egress, and writable locations.
5. Choose a callback payload for an installed runtime rather than cycling random reverse shells.
6. Transfer files only when needed and keep every hosted artifact in the evidence log.
7. Upgrade the shell enough to navigate and read proof.txt; privilege escalation is not required.

CHAIN

• Direct command output can retrieve proof without a reverse shell when the objective and screenshot rules are satisfied.
• Blind execution can download or invoke a short callback payload from your controlled HTTP server.
• Writable web roots may allow a web shell when outbound callbacks fail.

FUCKUPS

• Combining separators, encodings, and shell syntax before learning which character is blocked.
• Using bash-specific syntax when /bin/sh or Windows cmd is executing.
• Debugging a listener when the actual problem is quoting or target egress.
• Forgetting to screenshot proof from its original location.

EVIDENCE

• Harmless direct/timing confirmation
• Execution context enumeration
• Listener and target command
• Stable shell or direct file read
• Original-location proof

TOOLS

• Burp/ZAP resend and fuzzer
• curl or Python HTTP server
• nc/socat listener
• Reverse-shell generator

DETECT

• Features import URLs, generate previews, fetch images, validate webhooks, render PDFs, check links, proxy APIs, or accept callback destinations.
• A controlled server receives a request with headers or source addresses different from the browser.
• Supplying localhost, private IPs, or alternate schemes changes status, body, timing, or error text.

TEST

1. Use a unique callback path to prove the exact input causes a server-side request.
2. Record method, headers, DNS behavior, redirects, URL parsing, response reflection, and whether the server follows redirects.
3. Test loopback and likely internal services using controlled port and path hypotheses.
4. Evaluate alternate host representations, scheme confusion, userinfo, fragments, redirects, and validation-versus-fetch parser differences.
5. Distinguish blind reachability using timing or callbacks from content-retrieving SSRF.
6. Interact with internal administrative or unauthenticated microservice endpoints using the supported method and body.
7. Pursue cloud metadata only when environment clues support it and remain within the authorized target.

CHAIN

• Bypass network-based trust or authentication on localhost/internal services.
• Read internal API responses, configuration endpoints, or metadata credentials when reflected.
• Chain internal access into administrator actions, file access, or code execution.

FUCKUPS

• Mistaking a browser request for a server request.
• Scanning enormous private ranges instead of using application and error clues.
• Generating IP encodings without checking whether the actual URL parser accepts them.
• Stopping at a callback rather than reaching an exam objective.

EVIDENCE

• Unique callback request
• Server-fetch characteristics
• Internal destination evidence
• Privileged internal response/action
• Resulting objective

TOOLS

• Controlled HTTP/DNS callback
• Burp/ZAP resend
• SSRF representation workbench
• Nmap only against authorized exam targets as allowed

DETECT

• Requests contain numeric IDs, UUIDs, filenames, account names, nested object references, opaque tokens, or owner fields.
• The UI hides an operation but the endpoint remains callable.
• Responses differ when changing identity, method, path, body, content type, or object relationship.

TEST

1. Use two controlled accounts and label every session clearly in the proxy.
2. Create one object per account and record identifiers returned in paths, bodies, headers, links, and filenames.
3. Build a matrix for read, list, create, update, delete, download, share, and administrative operations.
4. Replay account A's request with account B's session while changing only the target object reference.
5. Test nested IDs, secondary identifiers, batch endpoints, alternate methods, content types, and direct file URLs.
6. Verify both the HTTP response and persistent side effect as the affected account.
7. Test vertical access to administrator objects and functions without relying only on predictable IDs.

CHAIN

• Read or modify an administrator-owned object that exposes an administrator feature or secret.
• Use unauthorized sharing, ownership transfer, role update, or file access to cross the administrative boundary.
• Combine IDOR with stored content, file features, or server-side processing to reach another vulnerability class.

FUCKUPS

• Testing with only one account and assuming an object belongs to someone else.
• Changing the object ID and session at the same time, making the result ambiguous.
• Treating a 200 response as success without checking the returned object or side effect.
• Ignoring filenames, UUIDs, nested resources, and bulk operations because IDs are not sequential.

EVIDENCE

• Ownership setup for both accounts
• Original authorized request
• Single-variable unauthorized replay
• Victim-side verification
• Administrator objective

TOOLS

• Burp/ZAP session labels and resend
• IDOR matrix
• Browser profiles or containers
• Response diff workbench