Free Practice Questions for The SecOps Group CAP Exam

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.

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.

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.

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

Caching HTTP responses can pose security risks, especially for sensitive data, as cached responses might be accessed by unauthorized users (e.g., on a shared device). The goal is to identify the HTTP response header that prevents caching in the most secure way. Let’s evaluate the options:

Option A ("Cache-Control: no-cache, no-store"): Correct. The Cache-Control header with no-cache instructs clients to revalidate with the server before using a cached copy, and no-store prohibits caching entirely (no storage in any cache, including browser, proxy, or CDN). This combination ensures the response is not cached, providing the most secure prevention of caching for sensitive data.

Option B ("Secure-Cache: Enabled"): There is no standard HTTP header called Secure-Cache. This appears to be a made-up option and is not a valid mechanism for controlling caching.

Option C ("Cache-Control: Private"): The Cache-Control: Private directive allows caching but restricts it to the user’s private cache (e.g., browser cache), preventing shared caches (e.g., proxies) from storing the response. However, it still permits caching in the browser, which is less secure than preventing all caching, especially for sensitive data.

Option D ("Content-Security-Policy: no-cache, no-store"): The Content-Security-Policy (CSP) header is used to mitigate XSS and other attacks by controlling which resources can be loaded (e.g., scripts, images). It does not control caching, and no-cache, no-store are not valid CSP directives. This is incorrect.

The correct answer is A, as Cache-Control: no-cache, no-store is the most secure way to prevent caching, aligning with the CAP syllabus under "HTTP Headers Security" and "Sensitive Data Protection."References: SecOps Group CAP Documents - "HTTP Caching Security," "Cache-Control Directives," and "OWASP Secure Headers Project" sections.

A safe password must adhere to security best practices, including sufficient length, complexity, and resistance to common attacks (e.g., brute force, dictionary attacks). Let’s evaluate each option:

Option A ("Monday@123"): This password is weak because it combines a common word ("Monday") with a simple number and symbol pattern. It is vulnerable to dictionary attacks and does not meet complexity requirements (e.g., mixed case, special characters, and randomness).

Option B ("abcdef"): This is a sequence of letters with no numbers, special characters, or uppercase letters. It is extremely weak and easily guessable, making it unsafe.

Option C ("Sq0Jh819%ak"): This password is considered safe because it is at least 10 characters long, includes a mix of uppercase letters (S, J, H), lowercase letters (q, h, a, k), numbers (0, 8, 9, 1), and a special character (%). It lacks predictable patterns and meets modern password policy standards (e.g., NIST SP 800-63B recommends at least 8 characters with complexity).

Option D ("1234567890"): This is a simple numeric sequence, highly predictable, and vulnerable to brute-force attacks, making it unsafe.

The correct answer is C, as it aligns with secure password creation guidelines, a key topic in the CAP syllabus under "Authentication Security" and "Secure Coding Practices."References: SecOps Group CAP Documents - "Password Management," "Authentication Security," and "OWASP Secure Coding Guidelines" 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.

Let’s evaluate the two statements about NoSQL injection:

Statement A: NoSQL databases (e.g., MongoDB, Cassandra) are designed for scalability and flexibility, often sacrificing strict consistency for performance (e.g., eventual consistency in distributed systems). Unlike traditional SQL databases, they do not enforce rigid relational constraints, which simplifies scaling but does not eliminate the risk of injection attacks. Even without SQL syntax, NoSQL databases are vulnerable to injection if user input is not sanitized (e.g., in MongoDB, injecting $where or $ne operators). This statement is true.

Statement B: NoSQL database queries are typically written in the application’s programming language (e.g., JavaScript for MongoDB), using a custom API (e.g., MongoDB’s query API), or formatted in standards like JSON, XML, or LINQ. For example, a MongoDB query might look like db.collection.find({ "key": input }), where input is a JSON-like structure. This statement accurately describes how NoSQL queries are constructed and is true.

Option A ("A is true, and B is false"): Incorrect, as both statements are true.

Option B ("A is false, and B is true"): Incorrect, as both statements are true.

Option C ("Both A and B are false"): Incorrect, as both statements are true.

Option D ("Both A and B are true"): Correct, as both statements accurately describe NoSQL databases and their vulnerability to injection.

The correct answer is D, aligning with the CAP syllabus under "NoSQL Injection" and "Database Security."References: SecOps Group CAP Documents - "NoSQL Injection Vulnerabilities," "Database Query Security," and "OWASP Top 10 (A03:2021 - Injection)" sections.