The SecOps Group Certified AppSec Practitioner CAP Exam Practice Test

Answer : D

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

Answer : C

The code snippet shows HTML <meta> and <link> tags, along with a <script> tag, loading external resources:

Bootstrap CSS from cdnjs.cloudflare.com (version 4.1.1)

jQuery JavaScript from cdnjs.cloudflare.com (version 3.3.1)

Let's evaluate the potential vulnerabilities:

The resources are loaded from a third-party CDN (cdnjs.cloudflare.com), and the versions specified (Bootstrap 4.1.1 and jQuery 3.3.1) may have known vulnerabilities. For instance, jQuery 3.3.1 has known XSS (Cross-Site Scripting) vulnerabilities (e.g., CVE-2019-11358) that can be exploited if the library is used insecurely. Similarly, Bootstrap 4.1.1 has known issues (e.g., CVE-2018-14041) related to XSS in certain components like tooltips or modals if not configured properly.

The use of outdated or vulnerable third-party components is a Component with a Known Vulnerability, a common issue in web applications. The CAP syllabus emphasizes identifying and mitigating risks from third-party libraries, especially those with known CVEs.

Option A ('SQL Injection'): SQL injection occurs in server-side database queries, not in client-side HTML or JavaScript loading. This code snippet does not involve database interaction, so this is incorrect.

Option B ('Type Juggling'): Type juggling is a PHP-specific vulnerability where loose type comparison (== vs ===) leads to security issues. This code is HTML/JavaScript, not PHP, so type juggling does not apply.

Option C ('Component with a Known Vulnerability'): As explained, the use of potentially outdated jQuery and Bootstrap versions introduces the risk of known vulnerabilities, making this the most applicable answer.

Option D ('Server-Side Request Forgery'): SSRF involves tricking the server into making unauthorized requests, which is not relevant here as the code loads resources in the browser, not on the server.

The correct answer is C, aligning with the CAP syllabus under 'Component Vulnerabilities' and 'OWASP Top 10 (A09:2021 - Using Components with Known Vulnerabilities).'

Answer : D

SAML (Security Assertion Markup Language) is an XML-based standard for authentication and authorization, commonly used for single sign-on (SSO). Its reliance on XML and the complexity of its trust model make it vulnerable to several attacks:

Option A ('XML Signature Wrapping Attack'): This is a common SAML attack where an attacker manipulates the XML structure to wrap a malicious element while preserving the signature, tricking the relying party into accepting a forged assertion. This attack exploits the way SAML parsers handle signed XML messages.

Option B ('XML External Entity Injection'): SAML messages are XML-based, making them susceptible to XXE (XML External Entity) attacks if the XML parser is misconfigured. An attacker can include external entities to access local files or make network requests, compromising the system.

Option C ('Assertion Replay Attack'): In this attack, an attacker intercepts a valid SAML assertion and reuses it to impersonate the user. If the assertion lacks proper replay protection (e.g., timestamps, nonces), the relying party may accept the replayed assertion as valid.

Option D ('All of the above'): Correct, as all three attacks (XML Signature Wrapping, XXE Injection, and Assertion Replay) are well-documented vulnerabilities in SAML implementations.

The correct answer is D, aligning with the CAP syllabus under 'SAML Security' and 'XML-Based Attacks.'

Answer : A

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

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 : D

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

Answer : A

The payload {{7*7}} is a common test string used to detect Server-Side Template Injection (SSTI) vulnerabilities. SSTI occurs when user input is improperly rendered within a server-side template engine (e.g., Jinja2, Freemarker, or Handlebars), allowing the execution of arbitrary template expressions. If the server evaluates {{7*7}} and returns 49 (the result of 7 multiplied by 7), it indicates that the server is processing the input as a template expression, confirming an SSTI vulnerability. This can potentially lead to remote code execution if the template engine supports advanced features.

Option A ('Server Side Template Injection (SSTI)'): Correct, as {{7*7}} is a standard payload to test for SSTI by checking if the server evaluates the expression.

Option B ('Client-Side Template Injection (CSTI)'): Incorrect, as CSTI involves client-side rendering (e.g., JavaScript templates like Mustache), and {{7*7}} would not be evaluated on the client unless explicitly designed to do so, which is not implied here.

Option C ('Both 1 and 2'): Incorrect, as the payload specifically targets server-side processing.

Option D ('None of the above'): Incorrect, as SSTI is applicable.

The correct answer is A, aligning with the CAP syllabus under 'Server-Side Template Injection' and 'Input Validation.'