The SecOps Group Certified AppSec Practitioner CAP Exam Questions

Answer : A

The robots.txt file is a text file placed in a website's root directory to communicate with web crawlers (e.g., Googlebot) about which pages or resources should not be accessed or indexed. It uses directives like Disallow to specify restricted areas (e.g., Disallow: /admin/). However, robots.txt is not a security mechanism; it is only a request to crawlers, and malicious bots or users can ignore it.

Option A ('Developers must not list any sensitive files and directories in this file'): Correct. Listing sensitive files or directories (e.g., Disallow: /secret/) in robots.txt can inadvertently expose their existence to attackers, who can then attempt to access them directly. The best practice is to avoid mentioning sensitive paths and rely on proper access controls (e.g., authentication, authorization) instead.

Option B ('Developers must list all sensitive files and directories in this file to secure them'): Incorrect. Listing sensitive paths in robots.txt does not secure them; it only informs crawlers to avoid them, and it can serve as a roadmap for attackers.

Option C ('Both A and B'): Incorrect, as A and B are contradictory; B is false.

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

The correct answer is A, aligning with the CAP syllabus under 'Web Crawler Security' and 'Information Disclosure Prevention.'

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

The vulnerability described is an Insecure Direct Object Reference (IDOR), where manipulating the order_id (e.g., 53870) allows unauthorized access to other users' orders. The fixes proposed by Bob and John aim to obscure the numeric value of order_id to prevent easy guessing or manipulation:

Bob's Fix (SHA1 Hash): Replaces order_id=53870 with order_id=1ff0fe6f1599536d1326418124a261bc98b8ea1 (SHA1 hash of 53870). While this obscures the original value, an attacker can still attempt to hash potential order IDs (e.g., 53871, 53872) and test them in the URL. If the application directly uses the hash to look up the order without validating the user's authorization, the vulnerability persists. SHA1 is a one-way hash, but it does not inherently enforce access control.

John's Fix (Base64 Encoding): Replaces order_id=53870 with order_id=NTM4NzA= (Base64 encoding of 53870). Base64 is a reversible encoding, and an attacker can easily decode NTM4NzA= back to 53870 using standard tools. If the application decodes it and uses the original value to fetch orders without authorization checks, the IDOR vulnerability remains.

Evaluation: Both fixes address the symptom (disclosing the numeric value) but fail to address the root cause: lack of authorization validation. The application must ensure that only the authenticated user can access their own orders, regardless of the order_id format (numeric, hashed, or encoded). Neither fix includes such a check, so the vulnerability persists.

Option A ('Both solutions are adequate to fix the problem'): Incorrect, as neither solution enforces authorization.

Option B ('Both solutions are inadequate and the vulnerability is still not fixed'): Correct, as both SHA1 hashing and Base64 encoding are superficial changes that do not prevent unauthorized access.

Option C ('Only John's solution fixes the problem'): Incorrect, as John's Base64 encoding is reversible and does not fix the IDOR issue.

Option D ('Only Bob's solution fixes the problem'): Incorrect, as Bob's SHA1 hashing also does not address the authorization flaw.

The correct answer is B, aligning with the CAP syllabus under 'Insecure Direct Object Reference (IDOR)' and 'Access Control Best Practices.'

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

The HTTP response headers provide metadata about the server and its configuration. Let's analyze each header and evaluate the statements:

Headers Breakdown:

Server: Microsoft-IIS/8.0: Indicates the web server is Microsoft Internet Information Services (IIS) version 8.0.

X-AspNet-Version: 2.0.50727: Indicates the application is using ASP.NET version 2.0.50727.

X-Powered-By: ASP.NET: Confirms the application framework is ASP.NET.

Other headers (e.g., Cache-Control, Content-Type, Expires) are standard and not directly relevant to the statements.

Option A ('The application is using an outdated server technology'): The Server: Microsoft-IIS/8.0 header indicates the server is running IIS 8.0, which was released in 2012 and is associated with Windows Server 2012. As of the current date (March 06, 2025), IIS 8.0 is outdated; Microsoft has released newer versions (e.g., IIS 10 with Windows Server 2016/2019). Additionally, mainstream support for Windows Server 2012 ended in October 2018, and extended support ended in October 2023, making IIS 8.0 unsupported and vulnerable to unpatched security issues. This statement is true.

Option B ('The application is disclosing the server version'): The Server: Microsoft-IIS/8.0 header explicitly discloses the server type (IIS) and version (8.0). Disclosing server version information is a security risk because attackers can use this to identify known vulnerabilities specific to that version (e.g., CVE exploits for IIS 8.0). Best practice is to suppress or obfuscate this header (e.g., Server: WebServer), so this statement is true.

Option C ('The application is disclosing the version of the framework used'): The X-AspNet-Version: 2.0.50727 header reveals the ASP.NET framework version (2.0.50727), which corresponds to .NET Framework 2.0, released in 2005. Disclosing the framework version is a security risk because attackers can target known vulnerabilities in that version (e.g., .NET Framework 2.0 is long unsupported; support ended in 2011). Best practice is to disable this header in the application configuration (e.g., in web.config for ASP.NET), so this statement is true.

Option D ('All of the above'): Since A (outdated server technology), B (disclosing server version), and C (disclosing framework version) are all true, this is the correct answer.

The correct answer is D, aligning with the CAP syllabus under 'Information Disclosure' and 'HTTP Header Security.'