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

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols used to secure communication over a network. The security of these protocols has evolved over time, with older versions being deprecated due to identified vulnerabilities. SSLv2 and SSLv3 are considered insecure because they are vulnerable to attacks such as POODLE (Padding Oracle On Downgraded Legacy Encryption), which exploits weaknesses in their padding schemes. Similarly, TLSv1.0 and TLSv1.1 are also deemed insecure due to vulnerabilities like BEAST (Browser Exploit Against SSL/TLS) and weak cipher support, and they have been deprecated by modern standards (e.g., PCI DSS). TLSv1.2 and TLSv1.3 are considered secure when properly configured with strong ciphers.

Option A correctly identifies SSLv2 and SSLv3 as insecure, but it omits TLSv1.0 and TLSv1.1. Option B correctly identifies TLSv1.0 and TLSv1.1 as insecure but omits SSLv2 and SSLv3. Option C ('Both A and B') encompasses all insecure protocols (SSLv2, SSLv3, TLSv1.0, and TLSv1.1), making it the most comprehensive and correct answer. Option D is incorrect because it includes TLSv1.2 and TLSv1.3, which are secure when used with modern configurations. This aligns with the CAP syllabus focus on secure communication protocols and vulnerability management.

Answer : C

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 is Access-Control-Allow-Origin, which specifies which origins are permitted to access the resource. However, among the provided options, the closest related header is Access-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 a preflight 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.'

Answer : C

The HTTP request is a POST to /changepassword with a session cookie (JSESSIONID) and parameters new_password and confirm_password. Let's evaluate each option:

Option A ('The change password feature does not validate the user'): The request includes a JSESSIONID cookie, which typically indicates that the user is authenticated via a session. There's no evidence that user validation is absent, so this is not correct.

Option B ('The change password feature uses basic authorization'): Basic authorization would involve an Authorization: Basic header with a Base64-encoded username and password, which is not present here. The authentication appears to be session-based (via cookie), not basic auth, so this is incorrect.

Option C ('The change password feature is vulnerable to Cross-Site Request Forgery attack'): Cross-Site Request Forgery (CSRF) occurs when a malicious site tricks a user's browser into making an unintended request to another site where the user is authenticated. This request lacks a CSRF token (e.g., a unique, unpredictable token in the request body or header) to verify the request's legitimacy. The Sec-Fetch-Site: same-origin header indicates the request is currently from the same origin, but this is a browser feature, not a server-side CSRF protection. Without a CSRF token, the endpoint is vulnerable to CSRF, as an attacker could craft a malicious form on another site to submit this request on behalf of the user. This is the correct answer.

Option D ('All of the above'): Since A and B are incorrect, D cannot be correct.

The correct answer is C, aligning with the CAP syllabus under 'Cross-Site Request Forgery (CSRF)' and 'OWASP Top 10 (A08:2021 - Software and Data Integrity Failures).'

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

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

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