Free The SecOps Group Certified AppSec Practitioner Exam CAP Exam Questions

In WordPress, the file that stores database connection details, including the database name, username, password, and host, is wp-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.'

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

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

SQL injection vulnerabilities allow attackers to manipulate database queries, potentially accessing unauthorized data, including file contents, if the database supports such operations. In MySQL, the LOAD_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.'

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 Reference (IDOR).'

The request is a POST to /dashboard/userdata with a parameter useragent=http://127.0.0.1/admin. The response is a 200 OK with an HTML page titled 'Admin Panel,' suggesting the server processed the request and returned content from http://127.0.0.1/admin. Let's evaluate the vulnerability:

Analysis: The useragent parameter contains a URL (http://127.0.0.1/admin), and the server appears to fetch content from this URL, as indicated by the response containing the 'Admin Panel' page. The URL 127.0.0.1 refers to the server's localhost, meaning the server is making an internal request to itself based on user input. This is a hallmark of Server-Side Request Forgery (SSRF), where an attacker can trick the server into making requests to arbitrary locations, including internal systems (e.g., 127.0.0.1) or external sites. SSRF can lead to accessing internal resources (e.g., admin panels, metadata endpoints) or performing unauthorized actions.

Option A ('HTTP Desync Attack'): HTTP Desync attacks exploit discrepancies in how front-end and back-end servers interpret HTTP requests (e.g., smuggling requests). This scenario involves a straightforward POST request with no evidence of desynchronization or smuggling, so this is incorrect.

Option B ('File Path Traversal Attack'): File Path Traversal involves manipulating file paths (e.g., ../../etc/passwd) to access unauthorized files on the server's filesystem. The useragent parameter contains a URL, not a file path, and the response indicates a web request, not filesystem access, so this is incorrect.

Option C ('Open URL Redirection'): Open URL Redirection occurs when the server redirects the client to a user-supplied URL (e.g., via a Location header). The response here is a 200 OK, not a redirect (e.g., 302 Found), and the server is fetching content server-side, not redirecting the client, so this is incorrect.

Option D ('Server-Side Request Forgery'): Correct, as the server is making a request to http://127.0.0.1/admin based on the useragent parameter, indicating an SSRF vulnerability.

The correct answer is D, aligning with the CAP syllabus under 'Server-Side Request Forgery (SSRF)' and 'OWASP Top 10 (A10:2021 - Server-Side Request Forgery).'

Cross-Site Scripting (XSS) is a vulnerability that allows attackers to inject malicious scripts into web pages viewed by other users. These scripts execute in the context of the victim's browser, enabling various exploitations. Let's evaluate each option:

Option A ('Steal the user's session identifier stored on a non HttpOnly cookie'): This is possible with XSS. If a session cookie is not marked as HttpOnly (preventing JavaScript access), an attacker can use a script to access document.cookie and steal the session ID, leading to session hijacking.

Option B ('Steal the contents from the web page'): This is also possible. An XSS payload can manipulate the DOM, extract content (e.g., via innerHTML), and send it to the attacker, such as through a GET request to a malicious server.

Option C ('Steal the contents from the application's database'): This is not possible with XSS alone. XSS operates on the client side within the browser's sandbox and cannot directly access the server-side database. Database access requires server-side vulnerabilities (e.g., SQL injection), which is a separate attack vector. Thus, this exploitation is not feasible through XSS.

Option D ('Steal the contents from the user's keystrokes using keyloggers'): This is possible. An XSS script can inject a keylogger (e.g., using onkeydown events) to capture keystrokes and transmit them to the attacker, especially on pages where sensitive data (e.g., forms) is entered.

Therefore, the correct answer is C, as XSS cannot directly exploit the database. This distinction is crucial in understanding attack vectors, a core topic in the CAP syllabus under 'OWASP Top 10 (A03:2021 - Injection)' and 'XSS Mitigation.'

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.

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 a Path 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).'

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