The SecOps Group Certified AppSec Practitioner CAP Exam Questions

Answer : C

Clickjacking is an attack where a malicious site overlays a transparent iframe containing a legitimate site, tricking users into interacting with it unintentionally (e.g., clicking a button). The Content-Security-Policy (CSP) HTTP response header is used to mitigate various client-side attacks, including clickjacking, through specific directives. The frame-ancestors directive is the correct choice for preventing clickjacking. This directive specifies which origins are allowed to embed the webpage in an iframe, <frame>, or <object>. For example, setting frame-ancestors 'self' restricts framing to the same origin, effectively blocking external sites from embedding the page. This is a standard defense mechanism recommended by OWASP and other security frameworks.

Option A ('script-src') controls the sources from which scripts can be loaded, addressing XSS (Cross-Site Scripting) vulnerabilities but not clickjacking. Option B ('object-src') restricts the sources of plugins or embedded objects (e.g., Flash), which is unrelated to iframe-based clickjacking. Option D ('base-uri') defines the base URL for relative URLs in the document, offering no protection against framing attacks. The use of CSP with the frame-ancestors directive is a critical topic in the CAP syllabus under 'Security Headers' and 'OWASP Top 10' (UI Redressing).

Answer : D

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

Answer : D

Multifactor Authentication (MFA) enhances security by requiring multiple forms of verification (e.g., something you know, like a password, and something you have, like a one-time code) to authenticate a user. It is effective against attacks that rely on stolen credentials, but let's evaluate its impact on the listed vulnerabilities:

Option A ('Cross-Site Scripting Vulnerability'): XSS (Cross-Site Scripting) involves injecting malicious scripts into a web application that execute in the victim's browser. MFA does not prevent XSS because it occurs after authentication; an attacker can exploit XSS to steal session cookies or perform actions on behalf of the authenticated user, bypassing MFA's protection.

Option B ('Cross-Site Request Forgery Vulnerability'): CSRF (Cross-Site Request Forgery) tricks a user's browser into making unintended requests to a site where they are authenticated. MFA does not prevent CSRF because the attack leverages the user's existing session (post-authentication). The browser automatically sends cookies (e.g., session cookies) with the forged request, and MFA does not interfere with this process.

Option C ('Path Traversal Vulnerability'): Path Traversal allows an attacker to manipulate file paths (e.g., ../../etc/passwd) to access unauthorized files on the server. MFA does not prevent this because it is an application-level vulnerability unrelated to user authentication; an attacker with or without credentials can exploit it if the application fails to validate input.

Option D ('All of the above'): Correct, as MFA is designed to secure the authentication process, not to mitigate vulnerabilities like XSS, CSRF, or Path Traversal, which exploit application logic or session management after authentication.

The correct answer is D, aligning with the CAP syllabus under 'Multifactor Authentication' and 'Application Security Vulnerabilities.'

Answer : A

The xmlrpc.php endpoint is a file commonly associated with WordPress, a popular Content Management System (CMS). XML-RPC (XML Remote Procedure Call) is a protocol used for remote communication, and in WordPress, xmlrpc.php enables features like remote publishing, pingbacks, and trackbacks. However, it is also a frequent target for attacks (e.g., brute-force attacks, DDoS) if not properly secured or disabled when unnecessary. While other CMS platforms like Drupal may support XML-RPC, they typically do not use a file named xmlrpc.php by default; Drupal's XML-RPC functionality is often integrated into its core or modules (e.g., via xmlrpc.module) and uses different endpoints.

Option A ('WordPress'): Correct, as xmlrpc.php is a hallmark of WordPress installations.

Option B ('Drupal'): Incorrect, as Drupal does not use xmlrpc.php by default; its XML-RPC endpoints are different.

Option C ('Both A and B'): Incorrect, as xmlrpc.php is specific to WordPress.

Option D ('None of the above'): Incorrect, as WordPress is the correct match.

The correct answer is A, aligning with the CAP syllabus under 'CMS Security' and 'WordPress Vulnerabilities.'

Answer : B

The request is a GET to /userProfile.php with a sessionId parameter matching the JSESSIONID cookie, and the response is a 200 OK with an HTML page. Let's evaluate the statements:

Option A ('The application uses an insecure channel (non-TLS)'): The request uses http:// (inferred from the absence of https:// in the Host and GET line), indicating a non-TLS channel. However, the question asks about the 'application' (likely the server-side behavior), and the response does not explicitly confirm the channel used for the response. Modern browsers might enforce TLS, but the request suggests an insecure channel. This could be true, but it depends on the server's configuration, making it less certain without further context.

Option B ('The application uses an insecure HTTP method (GET) to send sensitive information'): Correct. The sessionId parameter in the URL (/userProfile.php?sessionId=7576572ce164646de967c759643d53031) is sensitive data, as it could be used to hijack the user's session. Using GET exposes this data in browser history, server logs, and referral headers, which is insecure. Best practice is to use POST for sensitive data to avoid such exposure. The JSESSIONID cookie is marked HttpOnly, mitigating some risks, but the sessionId in the URL remains a vulnerability.

Option C ('The application is vulnerable to Cross-Site Scripting attacks'): The response includes an HTML page with no visible user input or script execution. There's no evidence of unsanitized input or script injection (e.g., no dynamic content like <script> tags with user data). The X-Xss-Protection: 1; mode=block header (though not shown) would mitigate XSS if present, but the response alone does not indicate vulnerability, so this is incorrect.

Option D ('All of the above'): Incorrect, as only B is definitively true; A is uncertain without confirming the response channel, and C lacks evidence.

The correct answer is B, aligning with the CAP syllabus under 'HTTP Methods Security' and 'Session Management.'

Answer : B

Cross-Site Scripting (XSS) attacks occur when an attacker injects malicious scripts (e.g., JavaScript) into a web application, which are then executed in a victim's browser. Effective input validation is a key defense against XSS by ensuring that user input does not contain malicious content.

Option A ('Blacklisting HTML and other harmful characters'): Blacklisting involves blocking known harmful characters (e.g., <, >, &) or patterns. While this can mitigate some XSS attacks, it is not the most effective approach because blacklists can be bypassed (e.g., using alternate encodings, nested tags, or new attack vectors). Blacklisting is inherently reactive and prone to evasion.

Option B ('Whitelisting and allowing only trusted input'): Whitelisting involves defining a strict set of allowed characters or patterns (e.g., only alphanumeric characters for a username). This is the most effective method because it explicitly permits only safe input and rejects everything else, making it much harder for attackers to inject malicious scripts. For example, if a field expects a phone number, a whitelist might allow only digits, spaces, and dashes, rejecting any HTML or script tags outright.

Option C ('Using a Web Application Firewall (WAF)'): A WAF can help detect and block XSS attacks by filtering malicious requests, but it is not an input validation method. WAFs are a secondary defense and can be bypassed; they are not a substitute for proper validation at the application level.

Option D ('Marking Cookie as HttpOnly'): The HttpOnly flag prevents cookies from being accessed by JavaScript, mitigating the impact of XSS (e.g., stealing session cookies), but it does not prevent the XSS attack itself. It addresses the consequence, not the root cause, and is not an input validation technique.

The correct answer is B, aligning with the CAP syllabus under 'Cross-Site Scripting (XSS)' and 'Input Validation Best Practices.'

Answer : C

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