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 : A

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 the Access-Control-Allow-Origin and Access-Control-Allow-Credentials headers. When Access-Control-Allow-Origin is set to * (wildcard, allowing all origins), it permits any domain to make requests. However, if Access-Control-Allow-Credentials is 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.'

Answer : C

The HTTP request is a POST to /changepassword with a session cookie (JSESSIONID) and parameters new_password and confirm_password. Let's evaluate each option:

Option A ('The change password feature does not validate the user'): The request includes a JSESSIONID cookie, which typically indicates that the user is authenticated via a session. There's no evidence that user validation is absent, so this is not correct.

Option B ('The change password feature uses basic authorization'): Basic authorization would involve an Authorization: Basic header with a Base64-encoded username and password, which is not present here. The authentication appears to be session-based (via cookie), not basic auth, so this is incorrect.

Option C ('The change password feature is vulnerable to Cross-Site Request Forgery attack'): Cross-Site Request Forgery (CSRF) occurs when a malicious site tricks a user's browser into making an unintended request to another site where the user is authenticated. This request lacks a CSRF token (e.g., a unique, unpredictable token in the request body or header) to verify the request's legitimacy. The Sec-Fetch-Site: same-origin header indicates the request is currently from the same origin, but this is a browser feature, not a server-side CSRF protection. Without a CSRF token, the endpoint is vulnerable to CSRF, as an attacker could craft a malicious form on another site to submit this request on behalf of the user. This is the correct answer.

Option D ('All of the above'): Since A and B are incorrect, D cannot be correct.

The correct answer is C, aligning with the CAP syllabus under 'Cross-Site Request Forgery (CSRF)' and 'OWASP Top 10 (A08:2021 - Software and Data Integrity Failures).'

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

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols used to secure communication over a network. The security of these protocols has evolved over time, with older versions being deprecated due to identified vulnerabilities. SSLv2 and SSLv3 are considered insecure because they are vulnerable to attacks such as POODLE (Padding Oracle On Downgraded Legacy Encryption), which exploits weaknesses in their padding schemes. Similarly, TLSv1.0 and TLSv1.1 are also deemed insecure due to vulnerabilities like BEAST (Browser Exploit Against SSL/TLS) and weak cipher support, and they have been deprecated by modern standards (e.g., PCI DSS). TLSv1.2 and TLSv1.3 are considered secure when properly configured with strong ciphers.

Option A correctly identifies SSLv2 and SSLv3 as insecure, but it omits TLSv1.0 and TLSv1.1. Option B correctly identifies TLSv1.0 and TLSv1.1 as insecure but omits SSLv2 and SSLv3. Option C ('Both A and B') encompasses all insecure protocols (SSLv2, SSLv3, TLSv1.0, and TLSv1.1), making it the most comprehensive and correct answer. Option D is incorrect because it includes TLSv1.2 and TLSv1.3, which are secure when used with modern configurations. This aligns with the CAP syllabus focus on secure communication protocols and vulnerability management.

Answer : A

The scenario describes a vulnerability where a user can manipulate the order_id parameter in the URL (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 Reference (IDOR)' and 'OWASP Top 10 (A04:2021 - Insecure Design).'

Answer : D

The HTTP response headers provide metadata about the server and its configuration. Let's analyze each header and evaluate the statements:

Headers Breakdown:

Server: Microsoft-IIS/8.0: Indicates the web server is Microsoft Internet Information Services (IIS) version 8.0.

X-AspNet-Version: 2.0.50727: Indicates the application is using ASP.NET version 2.0.50727.

X-Powered-By: ASP.NET: Confirms the application framework is ASP.NET.

Other headers (e.g., Cache-Control, Content-Type, Expires) are standard and not directly relevant to the statements.

Option A ('The application is using an outdated server technology'): The Server: Microsoft-IIS/8.0 header indicates the server is running IIS 8.0, which was released in 2012 and is associated with Windows Server 2012. As of the current date (March 06, 2025), IIS 8.0 is outdated; Microsoft has released newer versions (e.g., IIS 10 with Windows Server 2016/2019). Additionally, mainstream support for Windows Server 2012 ended in October 2018, and extended support ended in October 2023, making IIS 8.0 unsupported and vulnerable to unpatched security issues. This statement is true.

Option B ('The application is disclosing the server version'): The Server: Microsoft-IIS/8.0 header explicitly discloses the server type (IIS) and version (8.0). Disclosing server version information is a security risk because attackers can use this to identify known vulnerabilities specific to that version (e.g., CVE exploits for IIS 8.0). Best practice is to suppress or obfuscate this header (e.g., Server: WebServer), so this statement is true.

Option C ('The application is disclosing the version of the framework used'): The X-AspNet-Version: 2.0.50727 header reveals the ASP.NET framework version (2.0.50727), which corresponds to .NET Framework 2.0, released in 2005. Disclosing the framework version is a security risk because attackers can target known vulnerabilities in that version (e.g., .NET Framework 2.0 is long unsupported; support ended in 2011). Best practice is to disable this header in the application configuration (e.g., in web.config for ASP.NET), so this statement is true.

Option D ('All of the above'): Since A (outdated server technology), B (disclosing server version), and C (disclosing framework version) are all true, this is the correct answer.

The correct answer is D, aligning with the CAP syllabus under 'Information Disclosure' and 'HTTP Header Security.'