CAP Certified AppSec Practitioner Exam Questions and Answers

Let’s evaluate the two statements about NoSQL injection:

Statement A: NoSQL databases (e.g., MongoDB, Cassandra) are designed for scalability and flexibility, often sacrificing strict consistency for performance (e.g., eventual consistency in distributed systems). Unlike traditional SQL databases, they do not enforce rigid relational constraints, which simplifies scaling but does not eliminate the risk of injection attacks. Even without SQL syntax, NoSQL databases are vulnerable to injection if user input is not sanitized (e.g., in MongoDB, injecting $where or $ne operators). This statement is true.

Statement B: NoSQL database queries are typically written in the application’s programming language (e.g., JavaScript for MongoDB), using a custom API (e.g., MongoDB’s query API), or formatted in standards like JSON, XML, or LINQ. For example, a MongoDB query might look like db.collection.find({ "key": input }), where input is a JSON-like structure. This statement accurately describes how NoSQL queries are constructed and is true.

Option A ("A is true, and B is false"): Incorrect, as both statements are true.

Option B ("A is false, and B is true"): Incorrect, as both statements are true.

Option C ("Both A and B are false"): Incorrect, as both statements are true.

Option D ("Both A and B are true"): Correct, as both statements accurately describe NoSQL databases and their vulnerability to injection.

The correct answer is D, aligning with the CAP syllabus under "NoSQL Injection" and "Database Security."References: SecOps Group CAP Documents - "NoSQL Injection Vulnerabilities," "Database Query Security," and "OWASP Top 10 (A03:2021 - Injection)" sections.

The screenshot shows an HTTP response header from https://example.com with a 404 status. Let’s evaluate each option:

Option A ("The application discloses the framework name and version"): The X-Powered-By: PHP/5.4.5-5 header reveals the server is running PHP version 5.4.5-5, which is a security risk as it exposes the framework and version. This information can help attackers identify known vulnerabilities, making A incorrect (i.e., it is a problem).

Option B ("The application reveals user-agent details"): The response does not include user-agent details; it only shows the server’s configuration. User-agent details are part of the request, not the response, so this is incorrect (not a problem here).

Option C ("A cookie is set with HttpOnly and a Secure flag"): The Cookie header includes HttpOnly and Secure attributes, which are best practices to prevent JavaScript access and ensure transmission over HTTPS, respectively. This is correct behavior, so it is not incorrect.

Option D ("The application accepts insecure protocol"): The response uses https://, indicating a secure protocol (TLS), and there’s no evidence of accepting insecure protocols like HTTP. This is not incorrect.

Thus, the incorrect statement is A, as disclosing the framework name and version via X-Powered-By is a security misconfiguration. This aligns with the CAP syllabus under "Security Headers" and "Information Disclosure."References: SecOps Group CAP Documents - "Security Misconfigurations," "HTTP Headers," and "OWASP Top 10 (A05:2021 - Security Misconfiguration)" sections.

The request is a POST to /dashboard/userdata with a parameter useragent=https://127.0.0.1/admin. The response is a 200 OK with an HTML page titled "Admin Panel," suggesting the server processed the request and returned content from https://127.0.0.1/admin. Let’s evaluate the vulnerability:

Analysis: The useragent parameter contains a URL (https://127.0.0.1/admin), and the server appears to fetch content from this URL, as indicated by the response containing the "Admin Panel" page. The URL 127.0.0.1 refers to the server’s localhost, meaning the server is making an internal request to itself based on user input. This is a hallmark of Server-Side Request Forgery (SSRF), where an attacker can trick the server into making requests to arbitrary locations, including internal systems (e.g., 127.0.0.1) or external sites. SSRF can lead to accessing internal resources (e.g., admin panels, metadata endpoints) or performing unauthorized actions.

Option A ("HTTP Desync Attack"): HTTP Desync attacks exploit discrepancies in how front-end and back-end servers interpret HTTP requests (e.g., smuggling requests). This scenario involves a straightforward POST request with no evidence of desynchronization or smuggling, so this is incorrect.

Option B ("File Path Traversal Attack"): File Path Traversal involves manipulating file paths (e.g., ../../etc/passwd) to access unauthorized files on the server’s filesystem. The useragent parameter contains a URL, not a file path, and the response indicates a web request, not filesystem access, so this is incorrect.

Option C ("Open URL Redirection"): Open URL Redirection occurs when the server redirects the client to a user-supplied URL (e.g., via a Location header). The response here is a 200 OK, not a redirect (e.g., 302 Found), and the server is fetching content server-side, not redirecting the client, so this is incorrect.

Option D ("Server-Side Request Forgery"): Correct, as the server is making a request to https://127.0.0.1/admin based on the useragent parameter, indicating an SSRF vulnerability.

The correct answer is D, aligning with the CAP syllabus under "Server-Side Request Forgery (SSRF)" and "OWASP Top 10 (A10:2021 - Server-Side Request Forgery)."References: SecOps Group CAP Documents - "SSRF Vulnerabilities," "Input Validation for URLs," and "OWASP SSRF Prevention Cheat Sheet" sections.

CORS (Cross-Origin Resource Sharing) is a mechanism that allows servers to specify which origins can access their resources, enhancing security for cross-origin requests. A common misconfiguration occurs with theAccess-Control-Allow-OriginandAccess-Control-Allow-Credentialsheaders. WhenAccess-Control-Allow-Originis set to * (wildcard, allowing all origins), it permits any domain to make requests. However, ifAccess-Control-Allow-Credentialsis set to true (allowing credentials like cookies or HTTP authentication), this creates a security risk. Browsers will block such requests because sending credentials with a wildcard origin violates CORS security policies, but an attacker could exploit this misconfiguration to trick a victim’s browser into making unauthorized requests if other controls are absent.

Option A is correct because the combination of Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true is exploitable, as it enables potential credential leakage or unauthorized access. Option B is incorrect because Access-Control-Allow-Credentials: false disables credential sending, reducing exploitability. Option C is incorrect because the value of Access-Control-Allow-Credentials is not irrelevant; it must be false with a wildcard origin to comply with security standards. Option D ("All of the above") is incorrect as only A holds true. This is a key topic in the CAP syllabus under "CORS Misconfiguration" and "Client-Side Security."References: SecOps Group CAP Documents - "CORS Configuration," "Security Misconfigurations," and "OWASP Secure Headers" sections.

The scenario describes a password reset mechanism where a user receives an email with a reset link: https://example.com/reset_password?userId=5298. Let’s evaluate each option:

Option A ("The reset link uses an insecure channel"): The reset link uses https:// instead of https://, indicating an insecure channel (HTTP instead of HTTPS). Transmitting sensitive data (e.g., a reset link) over HTTP allows an attacker to intercept the request, potentially stealing the reset token or user ID. This makes the reset mechanism insecure, so this statement is true.

Option B ("The application is vulnerable to username enumeration"): The message "If the email exists, we will email you a link to reset the password" is generic and does not reveal whether the email exists, which is a best practice to prevent username enumeration. Username enumeration would occur if the application responded differently for existing vs. non-existing users (e.g., "Email not found"). Here, there’s no indication of enumeration vulnerability, so this statement is false.

Option C ("The application will allow the user to reset an arbitrary user’s password"): The reset link includes a userId=5298 parameter, which appears to directly reference a user’s ID. If an attacker can manipulate this parameter (e.g., to userId=5299), they might be able to reset another user’s password, especially if the application does not validate that the reset request is tied to the user’s session or email. The link also lacks a one-time token or other verification mechanism to ensure the request is legitimate. This suggests an Insecure Direct Object Reference (IDOR) vulnerability, making this statement true.

Option D ("Both A and C"): Since both A (insecure channel) and C (arbitrary password reset) are true, this is the correct answer.

The correct answer is D, aligning with the CAP syllabus under "Password Reset Security" and "Insecure Direct Object References (IDOR)."References: SecOps Group CAP Documents - "Password Reset Best Practices," "IDOR Vulnerabilities," and "OWASP Authentication Cheat Sheet" sections.

The scenario describes an e-commerce website where a user can view order details by manipulating the order_id parameter in the URL (e.g., https://example.com/order_id=53870). A security researcher found that changing the order_id allows access to arbitrary orders and sensitive data, indicating an authorization issue. This is not a simple input validation problem (e.g., SQL injection or path traversal), as the input (order_id) is processed, but the system fails to enforce proper access controls. This is a classic case of Insecure Direct Object References (IDOR), where an attacker can access resources by guessing or manipulating identifiers without proper authorization checks. The root cause is a weak authorization mechanism, likely tied to poor session management orprivilege validation, allowing unauthorized users to view others’ data.

Option A ("The root cause of the problem is a lack of input validation..."): Incorrect, as the issue is not about invalid input (e.g., malicious code) but about unauthorized access to valid data. Whitelisting might help sanitize input, but it doesn’t address authorization.

Option B ("The root cause of the problem is a weak authorization (Session Management)..."): Correct, as the problem stems from inadequate authorization checks. Validating user privileges (e.g., ensuring the user can only access their own orders) or improving session management (e.g., tying orders to user sessions) can fix this IDOR vulnerability.

Option C ("The problem can be solved by implementing a Web Application Firewall (WAF)"): Incorrect as a standalone solution, as WAFs mitigate certain attacks (e.g., SQLi, XSS) but are not a substitute for fixing authorization logic. A WAF might detect patterns but won’t enforce proper access control.

Option D ("None of the above"): Incorrect, as Option B accurately identifies the root cause and solution.

The correct answer is B, aligning with the CAP syllabus under "Authorization and Access Control" and "OWASP Top 10 (A04:2021 - Insecure Design)."References: SecOps Group CAP Documents - "Session Management," "Insecure Direct Object References (IDOR)," and "OWASP Top 10" sections.

Clickjacking is an attack where a malicious site tricks a user into clicking on something by overlaying a transparent iframe containing a legitimate site, exploiting the user’s clicks (e.g., clicking a button). The goal is to prevent a page from being embedded in a frame or iframe by unauthorized sites. Let’s evaluate the headers:

Option A ("Strict-Transport-Security"): HTTP Strict Transport Security (HSTS) enforces HTTPS connections by instructing browsers to only use secure connections, preventing man-in-the-middle attacks over HTTP. It does not address framing or clickjacking.

Option B ("Access-Control-Allow-Origin"): This CORS header specifies which origins can access resources, mitigating cross-origin resource sharing issues, but it does not prevent framing or clickjacking.

Option C ("X-Frame-Options"): Correct. The X-Frame-Options header controls whether a page can be embedded in an iframe. Values like DENY (block all framing) or SAMEORIGIN (allow only same-origin framing) prevent clickjacking by stopping malicious sites from embedding the page in a frame. This is a standard defense against clickjacking.

Option D ("X-Content-Type-Options"): This header prevents MIME-type sniffing by forcing browsers to respect the declared content type (e.g., nosniff), but it does not address framing or clickjacking.

The correct answer is C, aligning with the CAP syllabus under "Clickjacking Prevention" and"Security Headers."References: SecOps Group CAP Documents - "Clickjacking Defense," "Security Headers," and "OWASP Secure Headers Project" sections.

The code snippet is a Python script that takes user input for a filename, constructs a path by concatenating it with /var/www/html/files/, reads the file content, and prints it. The vulnerability arises because the filename variable is directly used in the path without sanitization or validation, allowing an attacker to manipulate it.

Path Traversal Vulnerability: An attacker can input a value like ../../etc/passwd to navigate outside the intended /var/www/html/files/ directory and access sensitive system files (e.g., /etc/passwd). Since the open() function will attempt to access the resulting path, this is a clear case of Path Traversal if the application runs with sufficient permissions.

Remote Code Execution (RCE): RCE would require the ability to execute arbitrary code, which is not directly possible here. The script only reads files, not executes them, unless the file contains executable code and the server interprets it (e.g., a PHP file on a web server),but this is not implied by the code alone.

Option A ("Path Traversal"): Correct, as the lack of input validation makes the code vulnerable to Path Traversal attacks.

Option B ("Remote Code Execution"): Incorrect, as the code does not execute the file content; it only reads it.

Option C ("Both A and B"): Incorrect, as RCE is not applicable here.

Option D ("None of the above"): Incorrect, as Path Traversal is a valid vulnerability.

The correct answer is A, aligning with the CAP syllabus under "Path Traversal Attacks" and "Input Validation."References: SecOps Group CAP Documents - "Path Traversal Vulnerabilities," "Input Sanitization," and "OWASP Top 10 (A05:2021 - Security Misconfiguration)" sections.

The scenario describes a vulnerability where a user can manipulate the order_id parameter in theURL (e.g., https://example.com/?order_id=53870) to access other users’ order details, indicating a lack of proper access control. This is a classic case of an Insecure Direct Object Reference (IDOR)attack. IDOR occurs when an application exposes a reference to an internal object (e.g., an order ID) that can be manipulated by an unauthorized user to access resources they should not have access to, without validating the user’s permissions.

Option A ("Insecure Direct Object Reference"): Correct, as the ability to change order_id to view arbitrary orders fits the definition of IDOR.

Option B ("Session Poisoning"): Incorrect, as session poisoning involves corrupting or altering a user’s session data, which is not indicated here.

Option C ("Session Riding OR Cross-Site Request Forgery"): Incorrect, as CSRF involves tricking a user into submitting a request (e.g., via a malicious form), not manipulating a URL parameter directly.

Option D ("Server-Side Request Forgery"): Incorrect, as SSRF involves tricking the server into making unauthorized requests to internal or external resources, which is not the case here.

The correct answer is A, aligning with the CAP syllabus under "Insecure Direct Object References (IDOR)" and "OWASP Top 10 (A04:2021 - Insecure Design)."References: SecOps Group CAP Documents - "IDOR Vulnerabilities," "Access Control," and "OWASP Testing Guide" sections.

Cross-Site Scripting (XSS) attacks occur when an attacker injects malicious scripts (e.g., JavaScript) into a web application, which are then executed in a victim’s browser. Effective input validation is a key defense against XSS by ensuring that user input does not contain malicious content.

Option A ("Blacklisting HTML and other harmful characters"): Blacklisting involves blocking known harmful characters (e.g., <, >, &) or patterns. While this can mitigate some XSS attacks, it is not the most effective approach because blacklists can be bypassed (e.g., using alternate encodings, nested tags, or new attack vectors). Blacklisting is inherently reactive and prone to evasion.

Option B ("Whitelisting and allowing only trusted input"): Whitelisting involves defining a strict set of allowed characters or patterns (e.g., only alphanumeric characters for a username). This is the most effective method because it explicitly permits only safe input and rejects everything else, making it much harder for attackers to inject malicious scripts. For example, if a field expects a phone number, a whitelist might allow only digits, spaces, and dashes, rejecting any HTML or script tags outright.

Option C ("Using a Web Application Firewall (WAF)"): A WAF can help detect and block XSS attacks by filtering malicious requests, but it is not an input validation method. WAFs are a secondary defense and can be bypassed; they are not a substitute for proper validation at the application level.

Option D ("Marking Cookie as HttpOnly"): The HttpOnly flag prevents cookies from being accessed by JavaScript, mitigating the impact of XSS (e.g., stealing session cookies), but it does not prevent the XSS attack itself. It addresses the consequence, not the root cause, and is not an input validation technique.

The correct answer is B, aligning with the CAP syllabus under "Cross-Site Scripting (XSS)" and "Input Validation Best Practices."References: SecOps Group CAP Documents - "XSS Prevention," "Input Validation and Sanitization," and "OWASP XSS Prevention Cheat Sheet" sections.

A JSON Web Token (JWT) consists of three parts separated by dots (.):Header,Payload, andSignature. Each part is Base64Url-encoded. The given JWT is:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJUYW1I1joiU2vjbB3ZiNo_mn0vNWT4G1-ATqOTmo7rm70VI12WCdkMI_S1_bPg_G8

The first part (eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9) is the Header, which typically includes metadata like the algorithm (alg) and type (typ). Decoding it gives: {"alg":"HS256","typ":"JWT"}.

The second part (eyJUYW1I1joiU2vjbB3ZiNo_mn0vNWT4G1-ATqOTmo7rm70VI12WCdkMI_S1_bPg_G8) is the Payload, which contains claims (e.g., user data, expiration). The highlighted segment corresponds to this second part, making it the Payload. Decoding it (though incomplete due to truncation) would reveal claims in JSON format.

The third part (not fully shown) would be the Signature, used to verify the token’s integrity.

Option A ("The highlighted segment of the token represents a JWT Header"): Incorrect, as the highlighted segment is the second part, which is the Payload.

Option B ("The highlighted segment of the token represents a JWT Payload"): Correct, as the highlighted segment is the Payload portion of the JWT.

Option C ("Both A and B are correct"): Incorrect, as only B is correct.

Option D ("None of the above"): Incorrect, as B is correct.

The correct answer is B, aligning with the CAP syllabus under "JWT Security" and "Token-Based Authentication."

References: SecOps Group CAP Documents - "JSON Web Tokens (JWT)," "Authentication Security," and "OWASP JWT Cheat Sheet" sections.

GraphQL Introspection is a built-in feature of GraphQL that allows clients to query the schema of a GraphQL API at runtime. This process involves sending introspection queries (e.g., __schema or __type) to retrieve information about the API’s structure, including available types, fields, queries, mutations, and their relationships. This capability is powerful for developers to explore and document APIs but poses a security risk if left enabled in production, as attackers can use it to map out the entire API structure and identify potential attack vectors.

Option A ("A technique for testing the compatibility of the GraphQL API with other systems"): Incorrect, as introspection is about schema discovery, not compatibility testing.

Option B ("A technique for testing the performance of the GraphQL API"): Incorrect, as performance testing involves load or stress testing, not schema exploration.

Option C ("A technique for discovering the structure of the GraphQL API"): Correct, as introspection is specifically designed to expose the API’s schema and structure.

Option D ("A technique for testing the security of the GraphQL API"): Incorrect, as security testing is a separate process; introspection itself is a feature, not a security test.

The correct answer is C, aligning with the CAP syllabus under "GraphQL Security" and "API Introspection."References: SecOps Group CAP Documents - "GraphQL Fundamentals," "Introspection Risks," and "OWASP API Security Top 10" sections.

Insecure Deserialization occurs when untrusted data is deserialized by an application, allowing attackers to execute arbitrary code, manipulate objects, or cause denial-of-service. If user input is not validated or sanitized, many languages and frameworks are vulnerable to this issue because deserialization often involves reconstructing objects from serialized data, which can include malicious payloads.

Option A (".NET"): .NET applications (e.g., using BinaryFormatter or XmlSerializer) areprone to Insecure Deserialization if untrusted data is deserialized without validation. For example, BinaryFormatter can execute arbitrary code during deserialization, a well-known vulnerability (e.g., CVE-2017-11882).

Option B ("Java"): Java’s ObjectInputStream is notoriously vulnerable to Insecure Deserialization. Libraries like java.io.Serializable can execute code during deserialization of untrusted data, as seen in vulnerabilities like Apache Commons Collections (CVE-2015-7501).

Option C ("PHP"): PHP applications using functions like unserialize() are vulnerable if they deserialize untrusted input. For example, an attacker can craft a serialized object to trigger a gadget chain, leading to remote code execution (e.g., CVE-2016-7124).

Option D ("All of the above"): Correct, as .NET, Java, and PHP all have deserialization mechanisms that, if not properly secured, can lead to Insecure Deserialization vulnerabilities when handling untrusted input.

The correct answer is D, aligning with the CAP syllabus under "Insecure Deserialization" and "OWASP Top 10 (A08:2021 - Software and Data Integrity Failures)."References: SecOps Group CAP Documents - "Insecure Deserialization," "Serialization Security," and "OWASP Deserialization Cheat Sheet" sections.

The payload {{7*7}} is a common test string used to detectServer-Side Template Injection (SSTI)vulnerabilities. SSTI occurs when user input is improperly rendered within a server-side template engine (e.g., Jinja2, Freemarker, or Handlebars), allowing the execution of arbitrary template expressions. If the server evaluates {{7*7}} and returns 49 (the result of 7 multiplied by 7), it indicates that the server is processing the input as a template expression, confirming an SSTI vulnerability. This can potentially lead to remote code execution if the template engine supports advanced features.

Option A ("Server Side Template Injection (SSTI)"): Correct, as {{7*7}} is a standard payload to test for SSTI by checking if the server evaluates the expression.

Option B ("Client-Side Template Injection (CSTI)"): Incorrect, as CSTI involves client-side rendering (e.g., JavaScript templates like Mustache), and {{7*7}} would not be evaluated on the client unless explicitly designed to do so, which is not implied here.

Option C ("Both 1 and 2"): Incorrect, as the payload specifically targets server-side processing.

Option D ("None of the above"): Incorrect, as SSTI is applicable.

The correct answer is A, aligning with the CAP syllabus under "Server-Side Template Injection" and "Input Validation."References: SecOps Group CAP Documents - "SSTI Vulnerabilities," "Template Engine Security," and "OWASP Injection Prevention" sections.

Cross-Site Request Forgery (CSRF) occurs when an attacker tricks a user’s browser into making an unintended request to a site where the user is authenticated, potentially performing actions like changing a password. Let’s analyze the request:

The request is a POST to /changepassword with a Cookie: JSESSIONID, indicating the user is authenticated via a session. The Content-Length: 95 and payload (new_password=lov3MyPiano23&confirm_password=lov3MyPiano23) suggest a state-changing operation (password change).

CSRF vulnerability arises when the request lacks a unique, unpredictable token to validate its legitimacy, and the server accepts it based solely on the session cookie. The request includes no CSRF token (e.g., in the body or headers like X-CSRF-Token).

The Sec-Fetch-Site: same-origin header indicates the request originates from the samedomain, but this is a browser feature and does not guarantee server-side protection against CSRF from a malicious site (e.g., via a hidden iframe or form submission).

Without a CSRF token, an attacker could craft a malicious HTML page with a form that submits this exact request when a victim visits their site while authenticated to example.com, exploiting the browser’s automatic inclusion of the JSESSIONID cookie. This is a textbook CSRF vulnerability.

Option A ("True"): Correct, as the request lacks a CSRF token, making it vulnerable to CSRF attacks.

Option B ("False"): Incorrect, as the absence of a CSRF token indicates vulnerability.

The correct answer is A, aligning with the CAP syllabus under "Cross-Site Request Forgery (CSRF)" and "Session Management."References: SecOps Group CAP Documents - "CSRF Prevention," "Session Security," and "OWASP CSRF Prevention Cheat Sheet" sections.