The SecOps Group CAP Certified AppSec Practitioner Exam Exam Practice Test

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.SSLv2andSSLv3are 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.0andTLSv1.1are 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.2andTLSv1.3are 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.References: SecOps Group CAP Documents - "Secure Communication," "SSL/TLS Configuration," and "OWASP Secure Headers" sections.

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

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.

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 xmlrpc.php endpoint is a file commonly associated with WordPress, a popular Content Management System (CMS). XML-RPC (XML Remote Procedure Call) is a protocol used for remote communication, and in WordPress, xmlrpc.php enables features like remote publishing, pingbacks, and trackbacks. However, it is also a frequent target for attacks (e.g., brute-force attacks, DDoS) if not properly secured or disabled when unnecessary. While other CMS platforms like Drupal may support XML-RPC, they typically do not use a file named xmlrpc.php by default; Drupal’s XML-RPC functionality is often integrated into its core or modules (e.g., via xmlrpc.module) and uses different endpoints.

Option A ("WordPress"): Correct, as xmlrpc.php is a hallmark of WordPress installations.

Option B ("Drupal"): Incorrect, as Drupal does not use xmlrpc.php by default; its XML-RPC endpoints are different.

Option C ("Both A and B"): Incorrect, as xmlrpc.php is specific to WordPress.

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

The correct answer is A, aligning with the CAP syllabus under "CMS Security" and "WordPress Vulnerabilities."References: SecOps Group CAP Documents - "Content Management System Security," "WordPress Hardening," and "OWASP CMS Security Guide" sections.

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 isAccess-Control-Allow-Origin, which specifies which origins are permitted to access the resource. However, among the provided options, the closest related header isAccess-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 apreflight 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."References: SecOps Group CAP Documents - "CORS Configuration," "Security Headers," and "OWASP Secure Headers Guide" 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.

A safe password must adhere to security best practices, including sufficient length, complexity, and resistance to common attacks (e.g., brute force, dictionary attacks). Let’s evaluate each option:

Option A ("Monday@123"): This password is weak because it combines a common word ("Monday") with a simple number and symbol pattern. It is vulnerable to dictionary attacks and does not meet complexity requirements (e.g., mixed case, special characters, and randomness).

Option B ("abcdef"): This is a sequence of letters with no numbers, special characters, or uppercase letters. It is extremely weak and easily guessable, making it unsafe.

Option C ("Sq0Jh819%ak"): This password is considered safe because it is at least 10 characters long, includes a mix of uppercase letters (S, J, H), lowercase letters (q, h, a, k), numbers (0, 8, 9, 1), and a special character (%). It lacks predictable patterns and meets modern password policy standards (e.g., NIST SP 800-63B recommends at least 8 characters with complexity).

Option D ("1234567890"): This is a simple numeric sequence, highly predictable, and vulnerable to brute-force attacks, making it unsafe.

The correct answer is C, as it aligns with secure password creation guidelines, a key topic in the CAP syllabus under "Authentication Security" and "Secure Coding Practices."References: SecOps Group CAP Documents - "Password Management," "Authentication Security," and "OWASP Secure Coding Guidelines" sections.

Null Byte Injection is a vulnerability where a null byte character (\0 or ASCII 0) is injected into user-supplied input to manipulate application behavior, often bypassing filters or terminating strings prematurely in languages like C or C++ that rely on null-terminated strings. In web applications, this is typically encoded in URLs using percent-encoding (e.g., %xx, where xx is the hexadecimal value). The ASCII value of a null byte is 0, which is represented as %00 in URL encoding.

Option A ("%01"): Represents the ASCII character with value 1 (Start of Heading), not a null byte.

Option B ("%10"): Represents the ASCII character with value 16 (Data Link Escape), not a null byte.

Option C ("%25"): Represents the % character itself (ASCII 37), not a null byte.

Option D ("%00"): Represents the null byte (ASCII 0), which is the correct URL-encoded form used in Null Byte Injection attacks.

The correct answer is D, aligning with the CAP syllabus under "Injection Attacks" and "Input Validation Bypasses."References: SecOps Group CAP Documents - "Null Byte Injection," "URL Encoding," and "OWASP Injection Prevention" sections.

A JWT consists of three parts:Header,Payload, andSignature, 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."References: SecOps Group CAP Documents - "JSON Web Tokens (JWT)," "Token Integrity," and "OWASP JWT Cheat Sheet" sections.

Salting is a security technique used in password hashing to enhance protection against specific types of attacks. A salt is a random value added to a password before hashing, ensuring that even if two users have the same password, their hashed outputs will differ. The primary objective of salting is to defend against dictionary attacks and rainbow table attacks. Dictionary attacks involve trying common passwords from a precomputed list, while rainbow table attacks use precomputed tables of hash values to reverse-engineer passwords quickly. By adding a unique salt to each password, the hash becomes unique, rendering precomputed rainbow tables ineffective, as an attacker would need to generate a new table for each salt, which is computationally impractical.

Option B ("To slow down the hash calculation process") is incorrect because while techniques like key stretching (e.g., using PBKDF2 or bcrypt) intentionally slow hashing to counter brute-force attacks, salting itself does not primarily aim to slow the process—it focuses on uniqueness. Option C ("To generate a long password hash that is difficult to crack") is a byproduct of salting but not the primary objective; the length and difficulty come from the hash function and salt combination, not salting alone. Option D ("To add a secret message to the password hash") is incorrect, as a salt is not a secret message but a random value, often stored alongside the hash. This aligns with best practices in authentication security, a key component of the CAP syllabus.

References: SecOps Group CAP Documents - "Secure Coding Practices," "Authentication Security," and "Cryptographic Techniques" sections.

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

Option A ("The reset link uses an insecure channel"): The reset link uses http:// 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.

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.

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.

Clickjacking is an attack where a malicious site overlays a transparent iframe containing a legitimate site, tricking users into interacting with it unintentionally (e.g., clicking a button). The Content-Security-Policy (CSP) HTTP response header is used to mitigate various client-side attacks, including clickjacking, through specific directives. The frame-ancestors directive is the correct choice for preventing clickjacking. This directive specifies which origins are allowed to embed the webpage in an iframe, , or