The SecOps Group CAP Certified AppSec Practitioner Exam Practice Test

Answer : D

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) are prone 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).'

Answer : D

A JWT consists of three parts: Header, Payload, and Signature, separated by dots (.). The given JWT is:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJUYW1I1joiU2vjbB3ZiNo_mn0vNWT4G1-ATqOTmo7rm70VI12WCdkMI_S1_bPg_G8

The first part (eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9) is the Header.

The second part (eyJUYW1I1joiU2vjbB3ZiNo_mn0vNWT4G1-ATqOTmo7rm70VI12WCdkMI_S1_bPg_G8) is the Payload.

The third part (not fully shown) would be the Signature, which is computed as HMAC-SHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret).

Option A ('eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 represents a JWT Signature'): Incorrect, as this is the Header, not the Signature.

Option B ('mn0vNWT4G1-ATqOTmo7rm70VI12WCdkMI_S1_bPg_G8 represents a JWT Signature'): Incorrect, as this is part of the Payload, not the Signature.

Option C ('eyJUYW1I1joiU2vjbB3ZiNo represents a JWT Signature'): Incorrect, as this is the beginning of the Payload, not the Signature.

Option D ('None of the above'): Correct, as none of the segments listed represent the JWT Signature (the third part, which is not fully shown).

The correct answer is D, aligning with the CAP syllabus under 'JWT Structure' and 'Token Security.'

Answer : B

A JSON Web Token (JWT) consists of three parts separated by dots (.): Header, Payload, and Signature. 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.'

Answer : D

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.'

Answer : D

SAML (Security Assertion Markup Language) is an XML-based standard for authentication and authorization, commonly used for single sign-on (SSO). Its reliance on XML and the complexity of its trust model make it vulnerable to several attacks:

Option A ('XML Signature Wrapping Attack'): This is a common SAML attack where an attacker manipulates the XML structure to wrap a malicious element while preserving the signature, tricking the relying party into accepting a forged assertion. This attack exploits the way SAML parsers handle signed XML messages.

Option B ('XML External Entity Injection'): SAML messages are XML-based, making them susceptible to XXE (XML External Entity) attacks if the XML parser is misconfigured. An attacker can include external entities to access local files or make network requests, compromising the system.

Option C ('Assertion Replay Attack'): In this attack, an attacker intercepts a valid SAML assertion and reuses it to impersonate the user. If the assertion lacks proper replay protection (e.g., timestamps, nonces), the relying party may accept the replayed assertion as valid.

Option D ('All of the above'): Correct, as all three attacks (XML Signature Wrapping, XXE Injection, and Assertion Replay) are well-documented vulnerabilities in SAML implementations.

The correct answer is D, aligning with the CAP syllabus under 'SAML Security' and 'XML-Based Attacks.'

Answer : C

A Dependency Confusion Attack occurs when an attacker uploads a malicious package with the same name as a private package to a public package repository (e.g., npm, PyPI), causing a package manager to prioritize the malicious public package over the intended private one due to misconfiguration or version precedence. To identify potential private packages for such an attack, attackers analyze dependency configuration files that list the application's dependencies.

Option A ('package.json'): This file is used by npm (Node.js package manager) to define dependencies for JavaScript projects. It lists package names and versions, making it a prime target for identifying private packages that might be targeted in a dependency confusion attack.

Option B ('requirements.txt'): This file is used by pip (Python package manager) to define dependencies for Python projects. It similarly lists package names and versions, making it another target for identifying private packages.

Option C ('Both A and B'): Correct, as both package.json (JavaScript/Node.js) and requirements.txt (Python) are dependency configuration files that can reveal private package names, which an attacker might exploit in a dependency confusion attack.

Option D ('None of the above'): Incorrect, as both files are relevant.

The correct answer is C, aligning with the CAP syllabus under 'Supply Chain Attacks' and 'Dependency Management.'

Answer : C

Cross-Origin Resource Sharing (CORS) is a security mechanism that allows servers to specify which origins can access their resources, relaxing the Same-Origin Policy (SOP) for legitimate cross-origin requests. CORS uses specific HTTP headers to control this access. The key header for controlling access to resources is Access-Control-Allow-Origin, which specifies which origins are permitted to access the resource. However, among the provided options, the closest related header is Access-Control-Allow-Headers, which is part of the CORS standard and controls which request headers can be used in the actual request (e.g., during a preflight OPTIONS request).

Option A ('Access-Control-Request-Method'): This header is sent by the client in a preflight request to indicate the HTTP method (e.g., GET, POST) that will be used in the actual request. It is not used by the server to control access.

Option B ('Access-Control-Request-Headers'): This header is sent by the client in a preflight request to list the headers it plans to use in the actual request. It is not used by the server to control access.

Option C ('Access-Control-Allow-Headers'): This header is sent by the server in response to a preflight request, specifying which headers are allowed in the actual request. While Access-Control-Allow-Origin is the primary header for controlling access, Access-Control-Allow-Headers is part of the CORS standard to manage header-based access control, making this the best match among the options.

Option D ('None of the above'): Incorrect, as Access-Control-Allow-Headers is a CORS header.

The correct answer is C, aligning with the CAP syllabus under 'CORS Security' and 'HTTP Headers.'