", "' OR '1'='1", "${jndi:ldap://test}" ], answer: 0, rationale: "Double curly brace expression syntax is common in engines such as Jinja2 and Twig. The other options target different vulnerability classes and are not a primary SSTI probe." }, { id: 7, domainCode: "3.0", domainName: "Basic Code Execution Primitives", question: "During SSTI testing in a Python/Jinja2 application, you want a minimal proof of code execution without immediately attempting file access or command execution. Which approach is most appropriate?", options: [ "Trigger a harmless arithmetic expression and verify server-side evaluation", "Upload a web shell to the server", "Force a DNS zone transfer", "Enable directory listing through the web server" ], answer: 0, rationale: "A harmless arithmetic expression proves evaluation with minimal impact and is the standard first step. More aggressive actions should only be attempted after confirming the issue and scope." }, { id: 8, domainCode: "3.0", domainName: "Basic Code Execution Primitives", question: "In a Flask/Jinja2 SSTI scenario, which object is commonly useful for exploring Python internals when direct builtins are not immediately exposed?", options: [ "request", "navigator", "window", "document" ], answer: 0, rationale: "The request object is available in many server-side contexts and can sometimes be leveraged to reach other objects or environment details. The other options are browser-side objects and are not relevant to server-side template evaluation." }, { id: 9, domainCode: "3.0", domainName: "Basic Code Execution Primitives", question: "What is the main advantage of using an expression that accesses template objects recursively rather than immediately trying to spawn a shell?", options: [ "It avoids needing any template engine at all", "It is less likely to break the application and helps map the execution context safely", "It guarantees outbound network connectivity", "It bypasses authentication automatically" ], answer: 1, rationale: "Recursive object traversal can reveal useful internals while staying low risk and minimizing impact. This is preferred during discovery and can help build a reliable exploitation path." }, { id: 10, domainCode: "4.0", domainName: "Sandbox and Filter Bypass", question: "A WAF blocks the characters used in your preferred SSTI payload, but the application still seems vulnerable. Which technique is most useful for bypassing simple blacklist filters?", options: [ "Stop testing because the WAF is proof of security", "Use alternative syntax or object traversal to reach the same primitive", "Perform a CSRF attack against the endpoint", "Switch to a different browser" ], answer: 1, rationale: "Blacklists often fail against alternate syntax, encoding tricks, or indirect object access. Effective testing adapts the payload while preserving the same underlying evaluation primitive." }, { id: 11, domainCode: "4.0", domainName: "Sandbox and Filter Bypass", question: "Which feature most commonly limits SSTI exploitation when the engine is configured in a restricted environment?", options: [ "A sandbox that blocks access to dangerous attributes and methods", "A larger HTTP response body", "A reverse proxy in front of the app", "An A record in DNS" ], answer: 0, rationale: "Sandboxing is specifically designed to prevent dangerous object access, method invocation, and code execution through templates. Network architecture and response size do not provide this direct restriction." }, { id: 12, domainCode: "4.0", domainName: "Sandbox and Filter Bypass", question: "A payload using direct attribute names is blocked, but the template still evaluates expressions. What is the best general workaround?", options: [ "Use indirect access to reach the same object or method through allowed references", "Decrease browser zoom level", "Change the request method to GET only", "Disable JavaScript on the page" ], answer: 0, rationale: "Indirect access is a standard way to bypass attribute filters when the engine still permits expression evaluation. This preserves the attack path while avoiding blocked keywords." }, { id: 13, domainCode: "5.0", domainName: "Command Execution and Post-Exploitation", question: "After confirming SSTI in a Linux-hosted application, you want to read a local file through the template engine. Which outcome best indicates success?", options: [ "The file contents are included in the HTTP response", "The browser downloads a ZIP archive automatically", "The page source contains only escaped HTML entities", "The server switches to HTTPS" ], answer: 0, rationale: "Successful file read through SSTI typically results in the requested file contents being returned in the response or embedded in rendered output. This is a common and controlled post-confirmation step." }, { id: 14, domainCode: "5.0", domainName: "Command Execution and Post-Exploitation", question: "Which action is generally the most appropriate when attempting to convert SSTI into operating system command execution in a lab environment?", options: [ "Use the template engine to reach a controllable execution primitive and then invoke a system command interface if available", "Brute force the admin password", "Exploit the browser with a malformed image tag", "Perform cache poisoning on every endpoint" ], answer: 0, rationale: "Exploitation typically requires moving from template evaluation to an object or function that can invoke system commands or equivalent execution. The other options are unrelated attack paths." }, { id: 15, domainCode: "5.0", domainName: "Command Execution and Post-Exploitation", question: "When a command injection payload is executed from a template context, which verification method is most appropriate and least disruptive?", options: [ "Use a command that produces a small, predictable output", "Run a denial-of-service loop to prove control", "Delete a system file to confirm privileges", "Encrypt the entire filesystem" ], answer: 0, rationale: "A small, predictable output is the safest way to verify command execution with minimal collateral impact. Destructive actions are not appropriate for validation." }, { id: 16, domainCode: "6.0", domainName: "Detection and Error Analysis", question: "During testing, a harmless payload causes a 500 error only when wrapped in a certain delimiter pattern. What is the most useful interpretation?", options: [ "The endpoint is definitely vulnerable to XSS", "The delimiter pattern is likely being parsed by a server-side template engine", "The response is proof of weak password storage", "The application is using client-side rendering exclusively" ], answer: 1, rationale: "Template parsers often fail on unexpected delimiters, producing a 500 error or parsing exception. This is a strong sign the payload is reaching a server-side template context." }, { id: 17, domainCode: "6.0", domainName: "Detection and Error Analysis", question: "Which artifact is most valuable for proving an SSTI finding in a professional report?", options: [ "A screenshot of the browser homepage only", "A before-and-after request/response pair showing controlled expression evaluation", "The victim's email address", "A list of all installed browser extensions" ], answer: 1, rationale: "A clear request/response pair demonstrates exactly how the input was transformed by the server and is strong evidence of the vulnerability. Reports should include reproducible proof with minimal ambiguity." }, { id: 18, domainCode: "6.0", domainName: "Detection and Error Analysis", question: "Which behavior most likely indicates output encoding rather than true mitigation of SSTI?", options: [ "The payload is rendered as literal text but still reaches a template boundary", "The server stops responding to all requests", "The browser clears its cache automatically", "The login form changes its field names" ], answer: 0, rationale: "Rendering literal text can mean the payload is being escaped, but it does not necessarily prove the template engine is not processing input elsewhere. True mitigation requires preventing evaluation, not just hiding visible output." }, { id: 19, domainCode: "7.0", domainName: "Hardening and Safe Validation", question: "Which mitigation is most effective against SSTI in a dynamic web application?", options: [ "Allowing users to define arbitrary template fragments", "Using untrusted input only as data, never as executable template syntax", "Increasing server RAM", "Changing the website theme" ], answer: 1, rationale: "The key defense is to avoid rendering untrusted input as template code. Treating user input strictly as data, combined with safe template design and escaping, prevents evaluation." }, { id: 20, domainCode: "7.0", domainName: "Hardening and Safe Validation", question: "A development team wants to test for SSTI safely before release. Which practice is best?", options: [ "Use a staging environment and controlled test payloads with logging enabled", "Test only in production during peak traffic", "Disable all error handling permanently", "Rely solely on browser-side alerts" ], answer: 0, rationale: "A staging environment with logging allows safe, repeatable validation without impacting real users. This approach is consistent with professional security testing and minimizes risk." } ] }); });