CAP Certified AppSec Practitioner Exam Questions and Answers

Symmetric key encryption algorithms use the same key for both encryption and decryption, while asymmetric algorithms use a pair of keys (public and private). Let’s evaluate the options:

Option A ("RC4"): RC4 is a symmetric key encryption algorithm. It is a stream cipher that uses a single key to both encrypt and decrypt data, though it is considered insecure due to known cryptographic weaknesses (e.g., biases in the keystream).

Option B ("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, widely regarded as secure when properly implemented.

Option C ("DES"): DES (Data Encryption Standard) is a symmetric key encryption algorithm. It uses a 56-bit key for both encryption and decryption, but it is now considered insecure due to its small key size and vulnerability to brute-force attacks.

Option D ("RSA"): RSA (Rivest-Shamir-Adleman) is an asymmetric key encryption algorithm. It uses a public key to encrypt and a private key to decrypt, making it an asymmetric algorithm, not a symmetric one.

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

The password reset mechanism now includes a one-time random token alongside the userId in the reset link: https://example.com/reset_password?userId=5298 &token=70e7803e-bf53-45e1-8a3f-fb15da7de3a0. Let’s evaluate the effectiveness of this mechanism:

Analysis: The inclusion of a one-time random token (e.g., 70e7803e-bf53-45e1-8a3f-fb15da7de3a0) is a best practice for secure password reset mechanisms. This token should be unique, unpredictable, and tied to the specific user’s reset request (e.g., stored in the database with an expiration time). When the user clicks the link, the application should verify that the token matches the one associated with the userId and that it hasn’t been used or expired.

Preventing Arbitrary Resets: Without the token, an attacker could manipulate the userId (e.g., to 5299) to reset another user’s password (as seen in Question 45). However, with the token, the attacker would need to guess the correct token for the targeted userId, which is computationally infeasible if the token is sufficiently random (e.g., a UUID or cryptographically secure random string) and properly validated. This prevents unauthorized password resets.

Additional Considerations: The link uses https://, ensuring a secure channel (unlike Question 45). The message "If the email exists..." prevents username enumeration, as discussed previously.

Option A ("True"): Correct, as the one-time random token, if implemented correctly (e.g., validated server-side, single-use, time-limited), prevents an attacker from resetting arbitrary users’ passwords.

Option B ("False"): Incorrect, as the mechanism is secure with the token.

The correct answer is A, aligning with the CAP syllabus under "Secure Password Reset" and "Token-Based Authentication."References: SecOps Group CAP Documents - "Password Reset Security," "Token Generation Best Practices," and "OWASP Forgot Password Cheat Sheet" 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.

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.

Hashing algorithms are used to securely store passwords by transforming them into fixed-length strings. A secure hashing algorithm for passwords should be resistant to collision attacks, preimage attacks, and brute-force attempts, and should be slow to compute to deter attackers. Let’s evaluate the options:

Option A ("SHA-0"): SHA-0 is the original version of the SHA family, published in 1993, but it was quickly withdrawn due to serious cryptographic weaknesses (e.g., collision vulnerabilities). It is not secure and should not be used.

Option B ("MD5"): MD5 is a widely used hash function but is cryptographically broken. It is vulnerable to collision attacks (e.g., practical attacks demonstrated since 2004) and is extremely fast, making it unsuitable for password hashing as it can be brute-forced easily.

Option C ("SHA-1"): SHA-1, part of the SHA family, is also considered broken for security purposes. It has known collision vulnerabilities (e.g., the SHAttered attack in 2017 demonstrated practical collisions), and like MD5, it is too fast for secure password hashing.

Option D ("Bcrypt"): Bcrypt is specifically designed for password hashing. It is a slow hashing algorithm with a configurable work factor (cost factor), making it resistant to brute-force attacks. It also includes a built-in salt to prevent rainbow table attacks. Bcrypt is widely recommended by security standards (e.g., OWASP, NIST) for secure password storage and is the most secure option among those listed.

The correct answer is D, aligning with the CAP syllabus under "Password Hashing" and "Cryptographic Best Practices."References: SecOps Group CAP Documents - "Secure Password Storage," "Hashing Algorithms," and "OWASP Password Storage Cheat Sheet" sections.

In WordPress, the file that stores database connection details, including the database name, username, password, and host, iswp-config.php. This file is located in the root directory of a WordPress installation and is critical for configuring the connection to the MySQL database. It contains constants like DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST, which must be protected from unauthorized access to prevent database compromise.

Option A ("wp-configuration.php"): A common misspelling; the correct file name lacks the extra "ation."

Option B ("wp-conf.php"): This is not a valid WordPress file name.

Option C ("wp-secret.php"): This is not a standard WordPress file.

Option D ("wp-config.php"): The correct and official file name used by WordPress.

The correct answer is D, aligning with the CAP syllabus under "Configuration Management" and "Application Security."References: SecOps Group CAP Documents - "Application Configuration," "WordPress Security," and "Database Security" 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.

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.

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.

A Race Condition vulnerability occurs in multi-threaded or multi-process applications when two or more threads access a shared resource concurrently, and the outcome depends on the non-deterministic order of their execution. This can lead to inconsistent states or security issues, such as privilege escalation or data corruption, if the access is not properly synchronized (e.g., using locks or semaphores). The classic definition focuses on concurrent access to the same resource.

Option A ("A situation that occurs when two threads access the same resource at the same time"): Correct, as this accurately describes a race condition where the lack of synchronization on a shared resource (e.g., a file, variable, or database entry) can lead to unpredictable behavior.

Option B ("A situation that occurs when two threads access different resources at the same time"): Incorrect, as race conditions specifically involve contention over the same resource, not different ones.

Option C ("A situation that occurs when a single thread unpredictably accesses two resources"): Incorrect, as race conditions require multiple threads or processes; a single thread’s behavior is not a race condition.

Option D ("A situation that occurs when a single thread predictably accesses two resources"): Incorrect, as predictability negates the race condition concept, and it still involves only one thread.

The correct answer is A, aligning with the CAP syllabus under "Race Condition Vulnerabilities" and "Multi-Threaded Security."References: SecOps Group CAP Documents - "Concurrency Issues," "Race Conditions," and "OWASP Secure Coding Practices" sections.

Cookies can have security attributes to protect them against various attacks. Let’s evaluate each option to determine which attribute is not used to secure cookies:

Option A ("HttpOnly"): The HttpOnly attribute prevents cookies from being accessed by JavaScript (e.g., via document.cookie). This mitigates XSS attacks that attempt to steal session cookies, making it a valid security attribute.

Option B ("Secure"): The Secure attribute ensures that the cookie is only sent over HTTPS connections, preventing it from being transmitted over unencrypted HTTP. This protects against interception (e.g., in a man-in-the-middle attack), making it a valid security attribute.

Option C ("Restrict"): There is no standard cookie attribute called Restrict. Cookie security attributes are well-defined (e.g., HttpOnly, Secure, SameSite), and Restrict does not exist in this context. This is not a valid attribute for securing cookies.

Option D ("Same-Site"): The SameSite attribute (e.g., SameSite=Strict or SameSite=Lax)controls whether a cookie is sent with cross-site requests. It helps mitigate CSRF attacks by ensuring the cookie is only sent with same-site requests (or limited cross-site scenarios), making it a valid security attribute.

The correct answer is C, as Restrict is not a recognized cookie attribute, aligning with the CAP syllabus under "Cookie Security" and "Session Management."References: SecOps Group CAP Documents - "Cookie Security Attributes," "Session Security," and "OWASP Session Management Cheat Sheet" sections.

Cookies can have security attributes to enhance their protection against various attacks. The question asks which attribute ensures that the cookie is only sent over a TLS (encrypted) channel, meaning it is transmitted securely via HTTPS and not over unencrypted HTTP.

Option A ("Secure"): The Secure attribute ensures that the browser only sends the cookie over a secure, encrypted connection (i.e., HTTPS). If a request is made over HTTP, the browser will not include the cookie, preventing it from being intercepted in plaintext. This is the correct answer.

Option B ("HttpOnly"): The HttpOnly attribute prevents the cookie from being accessed by JavaScript (e.g., via document.cookie), mitigating XSS attacks that steal cookies, but it does not enforce transmission over TLS.

Option C ("No_XSS"): This is not a valid cookie attribute; it appears to be a made-up termand does not relate to TLS enforcement.

Option D ("None of the above"): Incorrect, as the Secure attribute directly addresses the requirement.

The correct answer is A, aligning with the CAP syllabus under "Cookie Security" and "Session Management."References: SecOps Group CAP Documents - "Cookie Security Attributes," "Secure Session Management," and "OWASP Session Management 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.

The screenshot shows a login form where the user coder@viewer attempts to log in, and the application responds with "User does not exist." Let’s evaluate the statements:

Option A ("The application is vulnerable to username enumeration"): Correct. Username enumeration occurs when an application reveals whether a username exists in the system, often through distinct error messages. Here, the message "User does not exist" for coder@viewer directly indicates that the username is invalid, allowing an attacker to enumerate valid usernames by testing different inputs and observing the responses (e.g., "Invalid password" for existing users vs. "User does not exist"). Best practice is to use generic error messages like "Invalid username or password" to prevent enumeration.

Option B ("The application is vulnerable to brute-force attacks"): Incorrect. There’s no evidence in the screenshot of a lack of brute-force protections (e.g., rate limiting, account lockout). Brute-force vulnerability would require additional context, such as no CAPTCHA or no lockout mechanism, which is not shown.

Option C ("The application does not enforce a strong password policy"): Incorrect. The screenshot does not provide information about password requirements (e.g., length, complexity), so we cannot conclude whether a strong password policy is enforced.

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

The correct answer is A, aligning with the CAP syllabus under "Username Enumeration" and "Authentication Security."References: SecOps Group CAP Documents - "Authentication Best Practices," "Enumeration Attacks," and "OWASP Authentication Cheat Sheet" sections.

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)."References: SecOps Group CAP Documents - "CSRF Prevention," "Session Management," and "OWASP Secure Coding Practices" sections.