# OSWA complete checklist A combined download containing the universal methodology, every vulnerability playbook, evidence controls, and the study plan. A target-by-target workflow for deliberate WEB-200 testing and evidence capture. ## 00 · Prepare and preserve - [ ] Read the current exam guide, restrictions, proof rules, and target-specific control-panel objectives. - [ ] Confirm Kali, OpenVPN, browser, proxy certificate, terminal, screenshot tool, clock, disk space, and report template. - [ ] Create one notes folder and one evidence folder per target; start a command log before enumeration. - [ ] Record the VPN interface address and prepare callback variables for web servers, listeners, and out-of-band tests. - [ ] Bookmark the current official exam guide and this online reference; download the Markdown checklists you want in your own notes. - [ ] Start the report immediately. Do not rely on memory after a long exploitation chain. ## 01 · Map the application - [ ] Run focused host and service enumeration; note every HTTP and HTTPS port, title, redirect, certificate name, and technology clue. - [ ] Add required virtual hosts to /etc/hosts and repeat discovery against each hostname and port. - [ ] Browse every public feature through the proxy and record methods, paths, parameters, cookies, forms, APIs, uploads, and error behavior. - [ ] Discover directories, files, extensions, virtual hosts, parameters, parameter values, and backup artifacts with controlled wordlists. - [ ] Inspect HTML, JavaScript, source maps, comments, robots.txt, API documentation, and client-side requests for hidden routes. - [ ] Draw the authentication boundary: registration, login, reset, logout, session renewal, roles, administrator routes, and emulated-user entry points. - [ ] Create an input inventory covering path, query, form, JSON, XML, header, cookie, filename, file content, object ID, URL, and stored content. - [ ] Save clean baseline requests and responses for important features before mutation. ## 02 · Classify and prioritize - [ ] Classify each input as browser-rendered, database-consumed, filesystem-related, XML-parsed, template-rendered, command-adjacent, URL-fetched, or object-referencing. - [ ] Prioritize stored inputs visited by administrators, administrative actions, file or URL features, search/filter fields, import/export, and object identifiers. - [ ] For every promising input, record the source, transformations, sink, user context, and expected security boundary. - [ ] Rank hypotheses by ability to reach an administrator session, local.txt, file access, command execution, a shell, or proof.txt. - [ ] Define the smallest harmless probe that can confirm or reject each hypothesis. - [ ] Track negative results with the exact context and encoding used so failed tests are not repeated blindly. ## 03 · Confirm the primitive manually - [ ] Change one thing at a time and compare status, length, headers, body, timing, side effects, and subsequent requests. - [ ] Use delimiters, arithmetic, timing, callbacks, object swaps, or harmless file reads appropriate to the suspected sink. - [ ] Reproduce the signal at least twice and rule out caching, unstable content, proxy errors, and normal application behavior. - [ ] Identify the exact execution context, operating system, database dialect, template engine, parser, role, or URL parser where possible. - [ ] Save the minimum confirming request, response, command, and screenshot. - [ ] Only after manual confirmation, hand off repetitive enumeration to approved tools such as SQLMap, Tplmap, Wfuzz, or a proxy fuzzer. ## 04 · Escalate and chain - [ ] Ask whether the primitive runs in an administrator browser, application process, database, internal service, or another user's authorization context. - [ ] For browser-side execution, target the administrator session or a same-origin administrative action and verify the resulting role. - [ ] For database or server-side execution, enumerate the minimum information needed to reach file read, file write, command execution, or a shell. - [ ] For authorization issues, test horizontal and vertical operations across read, create, update, delete, file access, and administrative endpoints. - [ ] For SSRF and XXE, enumerate reachable local services and files methodically; do not confuse callback confirmation with objective completion. - [ ] Prefer short, reproducible chains. Record every dependency and transformation between source and final sink. - [ ] After a shell, locate proof.txt from its expected original location; privilege escalation is not required for OSWA. ## 05 · Capture evidence immediately - [ ] Submit local.txt and proof.txt values to the Exam Control Panel before the active exam ends. - [ ] For a web UI proof, capture the actual target browser view and the relevant request in Burp or another proxy. - [ ] For a shell proof, capture cat or type reading the file from its original location with target context visible. - [ ] Record commands, full requests, relevant responses, console output, payload hosting, listener setup, and every prerequisite step. - [ ] Use meaningful screenshot filenames and add them to the report while the chain is fresh. - [ ] Reproduce the chain from a clean session or clean target state before marking the target complete. - [ ] Confirm that another technically competent tester could repeat the result using only the report. ## 06 · Validate and submit - [ ] Calculate documented points, not merely discovered vulnerabilities; train for at least eight evidenced flags. - [ ] Review every target against its control-panel objective and verify every required screenshot is embedded. - [ ] Include scripts and PoCs as text in the PDF; do not rely on separate files inside the archive. - [ ] Render and review the final PDF for clipped commands, broken images, missing pages, and unreadable screenshots. - [ ] Name the PDF and .7z exactly as required, preserve case, do not password-protect the archive, and keep it under 200 MB. - [ ] Upload within the documentation window and compare the returned MD5 with the local archive hash. - [ ] Retain the final PDF, archive, checksum, and upload confirmation until results are received. > Do you want to live curiously? Trace untrusted data into an administrator-controlled browser context, obtain reliable JavaScript execution, and turn it into authenticated administrative access. ## Recognition - [ ] 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. ## Manual workflow - [ ] Locate the exact reflection or storage point and determine whether rendering is server-side or client-side. - [ ] Identify the context: HTML text, quoted/unquoted attribute, JavaScript string, URL, CSS, or DOM sink. - [ ] Use a harmless marker, then a context-appropriate execution proof. Avoid assuming a popup is the final objective. - [ ] Check encoding, sanitization, CSP, cookie HttpOnly/SameSite flags, and whether same-origin requests remain possible. - [ ] For an emulated administrator, host the smallest reliable callback payload and confirm the visit. - [ ] Use same-origin access or requests to reach the administrator area, then capture local.txt with the required browser/proxy evidence. ## Escalation - [ ] 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. ## Pitfalls - [ ] 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 ## Online references - [PortSwigger XSS labs]() - [OWASP XSS testing]() > Do you want to live curiously? Determine whether a cross-origin attacker can cause or read an authenticated action, then aim that primitive at an administrator objective. ## Recognition - [ ] 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. ## Manual workflow - [ ] Record method, content type, cookies, CSRF token, Origin/Referer behavior, redirects, and response requirements. - [ ] Remove or alter each anti-CSRF control independently and verify whether the state change still succeeds. - [ ] Determine whether a simple form is sufficient or JavaScript/CORS is required. - [ ] For CORS, vary Origin using exact attacker origins, null, scheme/port changes, subdomains, prefixes, and suffixes. - [ ] Confirm both browser acceptance and credential inclusion; permissive response headers alone may not be exploitable. - [ ] Chain the cross-origin primitive into an administrative read or state change that exposes the exam objective. ## Escalation - [ ] 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. ## Pitfalls - [ ] 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 ## Online references - [PortSwigger CSRF labs]() - [PortSwigger CORS labs]() > Do you want to live curiously? Prove SQL control manually, identify the dialect and query shape, then progress from data access to file or command execution where supported. ## Recognition - [ ] 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. ## Manual workflow - [ ] Establish a stable baseline and identify whether the value is numeric, string, list, identifier, ORDER BY, or function input. - [ ] Balance quotes and parentheses; test true/false conditions and native comments without combining many mutations. - [ ] Identify MySQL, PostgreSQL, MSSQL, or Oracle through errors, functions, concatenation, timing, and metadata behavior. - [ ] Count columns with ORDER BY or UNION NULLs and identify visible compatible columns. - [ ] Enumerate current database/user, schemas, tables, columns, and only the data required for the objective. - [ ] Evaluate stacked queries, file read/write, database-specific command execution, or web-shell placement. - [ ] After manual confirmation, use SQLMap narrowly with a saved request and known parameter when it reduces repetitive work. ## Escalation - [ ] 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. ## Pitfalls - [ ] 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 ## Online references - [PortSwigger SQL injection labs]() - [OWASP SQL injection testing]() > Do you want to live curiously? Understand how a path is constructed and normalized, then escape the intended directory to read application, operating-system, or authentication material. ## Recognition - [ ] 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. ## Manual workflow - [ ] Determine the expected base directory, filename, extension, prefix, suffix, and whether the application accepts absolute paths. - [ ] Test a known application file before distant operating-system paths so success is measurable. - [ ] Increase traversal depth methodically and test Unix/Windows separators appropriate to the target. - [ ] Evaluate URL encoding, double encoding, mixed separators, normalized dot segments, and validated-versus-used path differences. - [ ] Test whether an enforced suffix can be bypassed or whether the desired file already matches it. - [ ] Use controlled path wordlists only after learning the path grammar. - [ ] Read configuration or source material that advances authentication, command execution, or the requested proof. ## Escalation - [ ] 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. ## Pitfalls - [ ] 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 ## Online references - [PortSwigger traversal labs]() - [OWASP traversal testing]() > Do you want to live curiously? Confirm that attacker-controlled XML reaches an entity-capable parser, then use in-band, error, or out-of-band behavior for file or network access. ## Recognition - [ ] 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. ## Manual workflow - [ ] Preserve a valid baseline document and modify the smallest possible element. - [ ] Confirm entity expansion with a harmless internal entity before referencing local files or URLs. - [ ] Try in-band external entities when response data is reflected. - [ ] Use error-based or external-DTD techniques when direct output is unavailable. - [ ] Use a controlled callback to confirm blind retrieval and record DNS versus HTTP behavior. - [ ] Select files compatible with the parser and output context; binary or markup-heavy files may fail. - [ ] Chain file or network access to credentials, internal services, administrator access, or server execution. ## Escalation - [ ] 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. ## Pitfalls - [ ] 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 ## Online references - [PortSwigger XXE labs]() - [OWASP XXE testing]() > Do you want to live curiously? Distinguish server-side template evaluation from simple reflection, identify the engine, and navigate engine-specific objects toward file or command execution. ## Recognition - [ ] 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. ## Manual workflow - [ ] Use harmless arithmetic probes in multiple syntaxes and compare evaluated output with literal reflection. - [ ] Fingerprint Twig, Jinja, FreeMarker, Pug, Mustache, or Handlebars through syntax collisions and error language. - [ ] Map the rendering context, available variables, filters, functions, objects, and sandbox behavior. - [ ] Consult the exact engine/version documentation and construct the shortest engine-specific path. - [ ] Confirm low-impact server-side access before invoking operating-system commands. - [ ] Select a shell payload compatible with the server runtime and network reachability. - [ ] Record each object or function transition; template-engine payloads are brittle without context. ## Escalation - [ ] 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. ## Pitfalls - [ ] 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 ## Online references - [PortSwigger SSTI guide and labs]() - [PayloadsAllTheThings SSTI]() > Do you want to live curiously? Identify user input crossing into a system command, account for quoting and filters, then turn direct or blind execution into a stable shell. ## Recognition - [ ] 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. ## Manual workflow - [ ] Determine operating system, shell, command location, argument position, quoting, normalization, and allowed characters. - [ ] Try one appropriate separator or substitution construct with a harmless command. - [ ] When output is hidden, confirm with deterministic delay and then a controlled callback. - [ ] Enumerate identity, working directory, environment, available interpreters, egress, and writable locations. - [ ] Choose a callback payload for an installed runtime rather than cycling random reverse shells. - [ ] Transfer files only when needed and keep every hosted artifact in the evidence log. - [ ] Upgrade the shell enough to navigate and read proof.txt; privilege escalation is not required. ## Escalation - [ ] 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. ## Pitfalls - [ ] 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 ## Online references - [PortSwigger command injection labs]() - [OWASP command injection testing]() > Do you want to live curiously? Prove that the application—not the browser—fetches an attacker-influenced destination, then enumerate internal trust boundaries and services. ## Recognition - [ ] 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. ## Manual workflow - [ ] Use a unique callback path to prove the exact input causes a server-side request. - [ ] Record method, headers, DNS behavior, redirects, URL parsing, response reflection, and whether the server follows redirects. - [ ] Test loopback and likely internal services using controlled port and path hypotheses. - [ ] Evaluate alternate host representations, scheme confusion, userinfo, fragments, redirects, and validation-versus-fetch parser differences. - [ ] Distinguish blind reachability using timing or callbacks from content-retrieving SSRF. - [ ] Interact with internal administrative or unauthenticated microservice endpoints using the supported method and body. - [ ] Pursue cloud metadata only when environment clues support it and remain within the authorized target. ## Escalation - [ ] 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. ## Pitfalls - [ ] 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 ## Online references - [PortSwigger SSRF labs]() - [OWASP SSRF testing]() > Do you want to live curiously? Inventory object references and compare operations across identities to find missing horizontal or vertical authorization checks. ## Recognition - [ ] 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. ## Manual workflow - [ ] Use two controlled accounts and label every session clearly in the proxy. - [ ] Create one object per account and record identifiers returned in paths, bodies, headers, links, and filenames. - [ ] Build a matrix for read, list, create, update, delete, download, share, and administrative operations. - [ ] Replay account A's request with account B's session while changing only the target object reference. - [ ] Test nested IDs, secondary identifiers, batch endpoints, alternate methods, content types, and direct file URLs. - [ ] Verify both the HTTP response and persistent side effect as the affected account. - [ ] Test vertical access to administrator objects and functions without relying only on predictable IDs. ## Escalation - [ ] 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. ## Pitfalls - [ ] 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 ## Online references - [PortSwigger IDOR and access-control labs]() - [OWASP authorization testing]() > Do you want to live curiously? A final evidence, packaging, and submission review derived from the field manual. ## Evidence by vulnerability - [ ] Cross-site scripting: Vulnerable request and rendered response - [ ] Cross-site scripting: Exact context and payload - [ ] Cross-site scripting: Callback or administrator visit - [ ] Cross-site scripting: Authenticated administrator view - [ ] Cross-site scripting: local.txt browser and proxy screenshots - [ ] CSRF, SOP, SameSite, and CORS: Original privileged request - [ ] CSRF, SOP, SameSite, and CORS: Removed/bypassed control - [ ] CSRF, SOP, SameSite, and CORS: Browser-deliverable PoC - [ ] CSRF, SOP, SameSite, and CORS: Privileged side effect or readable response - [ ] CSRF, SOP, SameSite, and CORS: Administrator objective - [ ] SQL injection: True/false or error confirmation - [ ] SQL injection: Dialect identification - [ ] SQL injection: Working enumeration query - [ ] SQL injection: Administrative or RCE transition - [ ] SQL injection: Original-location proof screenshot - [ ] Directory traversal and file access: Baseline file request - [ ] Directory traversal and file access: Working traversal grammar - [ ] Directory traversal and file access: Known file contents - [ ] Directory traversal and file access: Sensitive file that advances the chain - [ ] Directory traversal and file access: Resulting administrator or server proof - [ ] XML external entity injection: Valid baseline XML - [ ] XML external entity injection: Internal expansion proof - [ ] XML external entity injection: External file or callback proof - [ ] XML external entity injection: Parser-specific payload - [ ] XML external entity injection: Chain to objective - [ ] Server-side template injection: Literal-versus-evaluated proof - [ ] Server-side template injection: Engine fingerprint - [ ] Server-side template injection: Accessible object/function - [ ] Server-side template injection: Command output or callback - [ ] Server-side template injection: proof.txt from original location - [ ] Operating-system command injection: Harmless direct/timing confirmation - [ ] Operating-system command injection: Execution context enumeration - [ ] Operating-system command injection: Listener and target command - [ ] Operating-system command injection: Stable shell or direct file read - [ ] Operating-system command injection: Original-location proof - [ ] Server-side request forgery: Unique callback request - [ ] Server-side request forgery: Server-fetch characteristics - [ ] Server-side request forgery: Internal destination evidence - [ ] Server-side request forgery: Privileged internal response/action - [ ] Server-side request forgery: Resulting objective - [ ] IDOR and broken object authorization: Ownership setup for both accounts - [ ] IDOR and broken object authorization: Original authorized request - [ ] IDOR and broken object authorization: Single-variable unauthorized replay - [ ] IDOR and broken object authorization: Victim-side verification - [ ] IDOR and broken object authorization: Administrator objective ## Submission - [ ] All local.txt and proof.txt values were entered into the Exam Control Panel before the active exam ended. - [ ] Every awarded objective has the required browser/proxy or shell/original-location screenshot. - [ ] Every attack is reproducible from the report, including commands, requests, output, callbacks, and PoCs. - [ ] Scripts and PoCs are included as text inside the PDF. - [ ] The final PDF was rendered and visually reviewed. - [ ] PDF name: OSWA-OS-XXXXX-Exam-Report.pdf. - [ ] Archive name: OSWA-OS-XXXXX-Exam-Report.7z. - [ ] The .7z is not password protected and is no larger than 200 MB. - [ ] The archive was uploaded within 24 hours after the active exam. - [ ] The upload MD5 matches the local md5sum output. > Do you want to live curiously? A practical study sequence with a readiness gate for each week. ## Week 1: Tools, proxy workflow, Nmap, wordlists, Gobuster, Wfuzz, crawling, shells, and XSS discovery - [ ] Map a fresh application and explain every captured request. ## Week 2: XSS exploitation, JavaScript APIs, stored/emulated-user paths, evidence - [ ] Turn context-specific XSS into a reliable callback and same-origin action. ## Week 3: Same-origin policy, SameSite, CSRF, CORS, browser enforcement - [ ] Build browser-deliverable CSRF and distinguish weak from exploitable CORS. ## Week 4: SQL fundamentals across MySQL, PostgreSQL, MSSQL, and Oracle - [ ] Write manual schema queries without copying a database dump recipe. ## Week 5: SQLi discovery, UNION, errors, stacked queries, file access, SQLMap handoff - [ ] Manually confirm and enumerate before running SQLMap. ## Week 6: Directory traversal, normalization, encoding, Unix and Windows file targets - [ ] Derive a working traversal from the application's path grammar. ## Week 7: XML and XXE: in-band, error-based, out-of-band - [ ] Prove entity expansion and retrieve a controlled file or callback. ## Week 8: SSTI fingerprinting across Twig, FreeMarker, Pug, Jinja, Mustache, Handlebars - [ ] Identify an engine from behavior and explain each escalation step. ## Week 9: Command injection, filters, blind confirmation, shells, transfer - [ ] Obtain a callback using a runtime you first proved exists. ## Week 10: SSRF, URL parsing, internal services, microservice trust, metadata - [ ] Differentiate server callback, blind reachability, and readable SSRF. ## Week 11: IDOR, two-account matrices, horizontal/vertical authorization, chaining - [ ] Demonstrate an unauthorized operation with a single-variable replay. ## Week 12: Unknown challenge targets, five-target simulation, screenshots, reporting, logistics - [ ] Score 80+ with complete evidence and produce the report without reopening targets. > Do you want to live curiously?