The Certified AppSec Practitioner Exam (CAP)

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)." References : SecOps Group CAP Documents - "SSRF Vulnerabilities," "Input Validation for URLs," and "OWASP SSRF Prevention Cheat Sheet" sections.

A JWT consists of three parts: Header , Payload , and Signature , 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.

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 Scripting attacks") : 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.

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.

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." References : SecOps Group CAP Documents - "Injection Vulnerabilities," "MySQL Security Features," and "OWASP Top 10 (A03:2021 - Injection)" 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.

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 same domain, 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.

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