CAP Certified AppSec Practitioner Exam Questions and Answers

Multifactor Authentication (MFA) enhances security by requiring multiple forms of verification (e.g., something you know, like a password, and something you have, like a one-time code) to authenticate a user. It is effective against attacks that rely on stolen credentials, but let’s evaluate its impact on the listed vulnerabilities:

Option A ("Cross-Site Scripting Vulnerability"): XSS (Cross-Site Scripting) involves injecting malicious scripts into a web application that execute in the victim’s browser. MFA does not prevent XSS because it occurs after authentication; an attacker can exploit XSS to steal session cookies or perform actions on behalf of the authenticated user, bypassing MFA’s protection.

Option B ("Cross-Site Request Forgery Vulnerability"): CSRF (Cross-Site Request Forgery) tricks a user’s browser into making unintended requests to a site where they are authenticated. MFA does not prevent CSRF because the attack leverages the user’s existing session (post-authentication). The browser automatically sends cookies (e.g., session cookies) with the forged request, and MFA does not interfere with this process.

Option C ("Path Traversal Vulnerability"): Path Traversal allows an attacker to manipulate file paths (e.g., ../../etc/passwd) to access unauthorized files on the server. MFA does not prevent this because it is an application-level vulnerability unrelated to user authentication; an attacker with or without credentials can exploit it if the application fails to validate input.

Option D ("All of the above"): Correct, as MFA is designed to secure the authentication process, not to mitigate vulnerabilities like XSS, CSRF, or Path Traversal, which exploit application logic or session management after authentication.

The correct answer is D, aligning with the CAP syllabus under "Multifactor Authentication" and "Application Security Vulnerabilities."References: SecOps Group CAP Documents - "MFA Implementation," "XSS/CSRF/Path Traversal Mitigation," and "OWASP Authentication Cheat Sheet" sections.

The screenshot shows an HTTP POST request to /upload.php with a multipart/form-data payload, where the attacker uploads a file named malicious.php disguised as an image/jpeg but containing PHP code (). This indicates an attempt to exploit aFile Upload Vulnerability. Such vulnerabilities occur when an application allows users to upload files without proper validation or sanitization, enabling attackers to upload malicious scripts (e.g., PHP) that can be executed on the server. In this case, if the server executes the uploaded malicious.php, it could expose server information via phpinfo() or perform other malicious actions.

Option A ("HTTP Desync Attack") involves manipulating HTTP request pipelines, which is not relevant here as the request appears standard. Option B ("File Path Traversal Attack") involves accessing unauthorized files using ../, which is not evident in this request. Option D ("Server-Side Request Forgery") involves tricking the server into making unintended requests, which does not apply to file uploads. Thus, C is the correct answer, aligning with the CAP syllabus under "File Handling Security" and "OWASP Top 10 (A05:2021 - Security Misconfiguration)."References: SecOps Group CAP Documents - "File Upload Vulnerabilities," "Input Validation," and "OWASP Top 10" sections.

SQL injection vulnerabilities allow attackers to manipulate database queries, potentially accessing unauthorized data, including file contents, if the database supports such operations. In MySQL, theLOAD_FILE()function is specifically designed to read the contents of a file on the server where the database is hosted, provided the file exists, the database user has appropriate privileges (e.g., FILE privilege), and the file is readable. For example, SELECT LOAD_FILE('/etc/passwd') could extract the contents of the /etc/passwd file if exploitable.

Option A ("READ_FILE()"): This is not a valid MySQL function.

Option B ("LOAD_FILE()"): This is the correct function for reading file contents in MySQL, making it the right choice for exploitation.

Option C ("FETCH_FILE()"): This is not a recognized MySQL function.

Option D ("GET_FILE()"): This is also not a valid MySQL function.

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

Asymmetric key encryption (also known as public-key cryptography) uses a pair of keys: a public key for encryption and a private key for decryption (or vice versa for signing). Symmetric key encryption, on the other hand, uses the same key for both encryption and decryption. Let’s evaluate the options:

Option A ("AES"): AES (Advanced Encryption Standard) is a symmetric key encryption algorithm. It uses a single key (e.g., 128, 192, or 256 bits) for both encryption and decryption, making it a symmetric algorithm, not an asymmetric one.

Option B ("RSA"): RSA (Rivest-Shamir-Adleman) is an asymmetric key encryption algorithm. It uses a public key to encrypt data and a private key to decrypt it, making it a classic example of asymmetric cryptography.

Option C ("Diffie-Hellman"): Diffie-Hellman is an asymmetric key exchange algorithm. While it is primarily used for key exchange rather than direct encryption, it relies on asymmetric principles (public and private keys) to securely establish a shared secret, so it is considered part of asymmetric cryptography.

Option D ("DSA"): DSA (Digital Signature Algorithm) is an asymmetric algorithm used for digital signatures. It uses a pair of keys (public and private) for signing and verification, making it an asymmetric algorithm.

The correct answer is A, as AES is the only symmetric algorithm listed, aligning with the CAP syllabus under "Cryptography Fundamentals" and "Symmetric vs. Asymmetric Encryption."References: SecOps Group CAP Documents - "Cryptographic Algorithms," "Symmetric and Asymmetric Encryption," and "OWASP Cryptographic Storage Cheat Sheet" sections.

The robots.txt file is a text file placed in a website’s root directory to communicate with web crawlers (e.g., Googlebot) about which pages or resources should not be accessed or indexed. It uses directives like Disallow to specify restricted areas (e.g., Disallow: /admin/). However, robots.txt is not a security mechanism; it is only a request to crawlers, and malicious bots or users can ignore it.

Option A ("Developers must not list any sensitive files and directories in this file"): Correct. Listing sensitive files or directories (e.g., Disallow: /secret/) in robots.txt can inadvertently expose their existence to attackers, who can then attempt to access them directly. The best practice is to avoid mentioning sensitive paths and rely on proper access controls (e.g., authentication, authorization) instead.

Option B ("Developers must list all sensitive files and directories in this file to secure them"): Incorrect. Listing sensitive paths in robots.txt does not secure them; it only informs crawlers to avoid them, and it can serve as a roadmap for attackers.

Option C ("Both A and B"): Incorrect, as A and B are contradictory; B is false.

Option D ("None of the above"): Incorrect, as A is true.

The correct answer is A, aligning with the CAP syllabus under "Web Crawler Security" and "Information Disclosure Prevention."References: SecOps Group CAP Documents - "robots.txt Usage," "Information Exposure," and "OWASP Web Security Testing Guide" sections.

A docker-compose.yml file is a YAML-formatted configuration file used with Docker Compose, a tool for defining and running multi-container Docker applications. Its primary significance lies in orchestrating the deployment of Docker containers by specifying services (e.g., web server, database), networks (e.g., internal communication), and volumes (e.g., persistent storage). An exposed docker-compose.yml file poses a security risk because it may reveal sensitive configuration details, such as service names, ports, environment variables (e.g., database credentials), and network settings, which attackers could exploit to target the application.

Option A ("The docker-compose.yml file is a YAML file that contains the application source code"): Incorrect, as this file defines configuration and orchestration, not source code.

Option B ("The docker-compose.yml file is a YAML file that contains the server logs and user session information..."): Incorrect, as logs and session data are stored elsewhere (e.g., in container logs or databases), not in docker-compose.yml.

Option C ("The docker-compose.yml file is a YAML file that is used to define the services, networks, and volumes..."): Correct, as it accurately describes the file’s purpose and content, including configuration and dependencies, which are critical for Docker applications.

Option D ("The docker-compose.yml file is a YAML file that contains the configuration of load balancers and firewalls"): Incorrect, as it focuses only on load balancers and firewalls, which are specific components and not the primary focus of the file.

The correct answer is C, aligning with the CAP syllabus under "Container Security" and "Configuration Management."References: SecOps Group CAP Documents - "Docker Security," "Container Orchestration," and "OWASP Application Security Verification Standard (ASVS)" sections.

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."References: SecOps Group CAP Documents - "SAML Security Risks," "XML Vulnerabilities," and "OWASP SAML Security Cheat Sheet" sections.

The HTTP request is a GET to /help.php with a parameter file=../../../etc/passwd. Let’s analyze the vulnerability:

The file parameter includes ../ sequences, which are used to navigate up the directory structure (.. moves up one directory level). The request attempts to access /etc/passwd, a sensitive system file on Linux servers that contains user information.

This is indicative of aPath Traversal Vulnerability(also known as Directory Traversal), where an attacker manipulates file paths to access unauthorized files outside the intended directory. If the server does not sanitize or restrict the file parameter, it may serve the contents of /etc/passwd, leading to sensitive information disclosure.

Option A ("Cross-Site Request Forgery Vulnerability"): CSRF involves tricking a user into making an unintended request, typically via a malicious form or link. This request does not indicate CSRF; it’s a direct attempt to manipulate file access, so this is incorrect.

Option B ("Path Traversal Vulnerability"): As explained, the ../ sequences in the file parameter are a clear attempt at path traversal, making this the correct answer.

Option C ("Code Injection Vulnerability"): Code injection involves executing malicious code (e.g., PHP, SQL), but this request aims to read a file, not execute code, so this is incorrect.

Option D ("All of the above"): Since only Path Traversal applies, this is incorrect.

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

Caching HTTP responses can pose security risks, especially for sensitive data, as cached responses might be accessed by unauthorized users (e.g., on a shared device). The goal is to identify the HTTP response header that prevents caching in the most secure way. Let’s evaluate the options:

Option A ("Cache-Control: no-cache, no-store"): Correct. The Cache-Control header with no-cache instructs clients to revalidate with the server before using a cached copy, and no-store prohibits caching entirely (no storage in any cache, including browser, proxy, or CDN). This combination ensures the response is not cached, providing the most secure prevention of caching for sensitive data.

Option B ("Secure-Cache: Enabled"): There is no standard HTTP header called Secure-Cache. This appears to be a made-up option and is not a valid mechanism for controlling caching.

Option C ("Cache-Control: Private"): The Cache-Control: Private directive allows caching but restricts it to the user’s private cache (e.g., browser cache), preventing shared caches (e.g., proxies) from storing the response. However, it still permits caching in the browser, which is less secure than preventing all caching, especially for sensitive data.

Option D ("Content-Security-Policy: no-cache, no-store"): The Content-Security-Policy (CSP) header is used to mitigate XSS and other attacks by controlling which resources can be loaded (e.g., scripts, images). It does not control caching, and no-cache, no-store are not valid CSP directives. This is incorrect.

The correct answer is A, as Cache-Control: no-cache, no-store is the most secure way to prevent caching, aligning with the CAP syllabus under "HTTP Headers Security" and "Sensitive Data Protection."References: SecOps Group CAP Documents - "HTTP Caching Security," "Cache-Control Directives," and "OWASP Secure Headers Project" sections.

TLS (Transport Layer Security) certificates are validated by browsers to ensure secure communication. Browsers maintain a trusted store ofpublic keysfrom known Certifying Authorities (CAs), which are used to verify the digital signature of a TLS certificate presented by a server. This process involves checking the certificate’s signature against the CA’s public key to confirm its authenticity and validity. If the signature matches and other criteria (e.g., expiration, revocation) are met, the certificate is deemed valid.

Option A ("The browser contains the private key..."): Incorrect, as browsers do not contain private keys of CAs; private keys are kept secret by the CAs themselves.

Option B ("The browser contains the public key..."): Correct, as browsers use CA publickeys to validate certificates, enabling differentiation between valid and invalid TLS certificates.

Option C ("The browser contains both the public and private key..."): Incorrect, as browsers only store public keys, not private keys, for security reasons.

Option D ("The browser does not have any mechanism..."): Incorrect, as browsers have robust mechanisms (via CA public keys) to validate TLS certificates.

The correct answer is B, aligning with the CAP syllabus under "Secure Communication" and "TLS Configuration."References: SecOps Group CAP Documents - "TLS/SSL Security," "Certificate Validation," and "OWASP Cryptographic Practices" 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 code snippet loads a JavaScript file from a third-party CDN with integrity and crossorigin attributes. Let’s analyze what these attributes do:

The integrity attribute specifies a Subresource Integrity (SRI) hash (e.g., sha384-Fmb0CYeA6gM2uLuyvqs7x75u0mktDh2nKLomp3PHkJ0b5vJF2qF6Gbrc/6dK), which the browser uses to verify the integrity of the loaded script. If the script’s content does not match the hash, the browser will not execute it, protecting against tampering (e.g., if the CDN is compromised).

The crossorigin="anonymous" attribute ensures the request does not send credentials (e.g., cookies) and allows the script to be loaded from a different origin while enabling CORS (Cross-Origin Resource Sharing).

Option A ("The code snippet will perform validations for Cross-Site Scriptingattacks"): Incorrect. XSS (Cross-Site Scripting) involves injecting malicious scripts into a page. The integrity attribute ensures the script’s integrity but does not validate the script’s content for XSS vulnerabilities (e.g., if the script itself contains malicious code). XSS prevention requires other measures, like Content Security Policy (CSP) or input sanitization.

Option B ("The code snippet will perform validations for Cross-Site Request Forgery attacks"): Incorrect. CSRF (Cross-Site Request Forgery) involves tricking a user into making unintended requests. The integrity and crossorigin attributes do not address CSRF, which requires server-side protections like CSRF tokens.

Option C ("The code snippet will perform Subresource Integrity (SRI) checks"): Correct. The integrity attribute explicitly enables SRI, ensuring the browser verifies the script’s hash before execution. This protects against supply chain attacks where a third-party script might be modified maliciously.

Option D ("The code snippet will perform validations for Outdated Javascript checks"): Incorrect. The snippet does not check for outdated JavaScript versions. SRI ensures the script matches the expected hash but does not validate the script’s version or security status.

The correct answer is C, aligning with the CAP syllabus under "Subresource Integrity (SRI)" and "Third-Party Script Security."References: SecOps Group CAP Documents - "SRI Implementation," "Third-Party Resource Security," and "OWASP Secure Coding Practices" 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.

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."References: SecOps Group CAP Documents - "Information Disclosure Prevention," "Server Hardening," and "OWASP Secure Headers Project" sections.

When multiple domain names (e.g.,www.ironman.com andwww.hulk.com ) resolve to the same IP address (e.g., 1.3.3.7), a web server hosting multiple applications on that IP must determine which application to serve. This is achieved using theHTTP "Host" header, which is part of the HTTP/1.1 protocol. The client (browser) includes the requested domain (e.g., Host: www.ironman.com) in the request, allowing the server to route the request to the appropriate virtual host or application configured for that domain. This is a standard practice in virtual hosting.

Option A ("The web server inspects the HTTP 'Host' header sent by the client"): Correct, as the Host header enables the server to distinguish between applications on the same IP.

Option B ("The web server inspects the cookies sent by the client"): Incorrect, as cookies are used for session management or personalization, not for identifying the requested application.

Option C ("The web server inspects the client's SSL certificate"): Incorrect, as SSL certificates are used for encryption and authentication, not for application routing (though they may include the domain name for validation).

Option D ("The web server uses a reverse DNS lookup of the client's IP address"): Incorrect, as reverse DNS lookup resolves an IP to a domain, which is irrelevant for the server determining the requested application.

The correct answer is A, aligning with the CAP syllabus under "Web Server Configuration" and "HTTP Protocol Security."References: SecOps Group CAP Documents - "HTTP Headers," "Virtual Hosting," and "OWASP Web Security Testing Guide" sections.