The SecOps Group secops-CAP Practice Exams
Last updated on Oct 22,2026- Exam Code: secops-CAP
- Exam Name: Certified AppSec Practitioner Exam
- Certification Provider: The SecOps Group
- Latest update: Oct 22,2026
Question #51
A robots.txt file tells the search engine crawlers about the URLs which the crawler can access on your site.
Which of the following is true about robots.txt?
- A . Developers must not list any sensitive files and directories in this file
- B . Developers must list all sensitive files and directories in this file to secure them
- C . Both A and B
- D . None of the above
Correct Answer: A
A
Explanation:
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."
Reference: SecOps Group CAP Documents – "robots.txt Usage," "Information Exposure," and "OWASP Web Security Testing Guide" sections.
A
Explanation:
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."
Reference: SecOps Group CAP Documents – "robots.txt Usage," "Information Exposure," and "OWASP Web Security Testing Guide" sections.
Question #52
In the context of a Dependency Confusion Attack, which of the following files is analyzed for determining potential private packages?
- A . package.json
- B . requirements.txt
- C . Both A and B
- D . None of the above
Correct Answer: C
C
Explanation:
A Dependency Confusion Attack occurs when an attacker uploads a malicious package with the same name as a private package to a public package repository (e.g., npm, PyPI), causing a package manager to prioritize the malicious public package over the intended private one due to misconfiguration or version precedence. To identify potential private packages for such an attack, attackers analyze dependency configuration files that list the application’s dependencies.
Option A ("package.json"): This file is used by npm (Node.js package manager) to define dependencies for JavaScript projects. It lists package names and versions, making it a prime target for identifying private packages that might be targeted in a dependency confusion attack.
Option B ("requirements.txt"): This file is used by pip (Python package manager) to define dependencies for Python projects. It similarly lists package names and versions, making it another
target for identifying private packages.
Option C ("Both A and B"): Correct, as both package.json (JavaScript/Node.js) and requirements.txt (Python) are dependency configuration files that can reveal private package names, which an attacker might exploit in a dependency confusion attack.
Option D ("None of the above"): Incorrect, as both files are relevant.
The correct answer is C, aligning with the CAP syllabus under "Supply Chain Attacks" and "Dependency Management."
Reference: SecOps Group CAP Documents – "Dependency Confusion Attacks," "Software Supply Chain Security," and "OWASP Dependency-Check Guide" sections.
C
Explanation:
A Dependency Confusion Attack occurs when an attacker uploads a malicious package with the same name as a private package to a public package repository (e.g., npm, PyPI), causing a package manager to prioritize the malicious public package over the intended private one due to misconfiguration or version precedence. To identify potential private packages for such an attack, attackers analyze dependency configuration files that list the application’s dependencies.
Option A ("package.json"): This file is used by npm (Node.js package manager) to define dependencies for JavaScript projects. It lists package names and versions, making it a prime target for identifying private packages that might be targeted in a dependency confusion attack.
Option B ("requirements.txt"): This file is used by pip (Python package manager) to define dependencies for Python projects. It similarly lists package names and versions, making it another
target for identifying private packages.
Option C ("Both A and B"): Correct, as both package.json (JavaScript/Node.js) and requirements.txt (Python) are dependency configuration files that can reveal private package names, which an attacker might exploit in a dependency confusion attack.
Option D ("None of the above"): Incorrect, as both files are relevant.
The correct answer is C, aligning with the CAP syllabus under "Supply Chain Attacks" and "Dependency Management."
Reference: SecOps Group CAP Documents – "Dependency Confusion Attacks," "Software Supply Chain Security," and "OWASP Dependency-Check Guide" sections.
Question #53
GraphQL is an open-source data query and manipulation language for APIs, and a query runtime engine. In this context, what is GraphQL Introspection?
- A . A technique for testing the compatibility of the GraphQL API with other systems
- B . A technique for testing the performance of the GraphQL API
- C . A technique for discovering the structure of the GraphQL API
- D . A technique for testing the security of the GraphQL API
Correct Answer: C
C
Explanation:
GraphQL Introspection is a built-in feature of GraphQL that allows clients to query the schema of a GraphQL API at runtime. This process involves sending introspection queries (e.g., __schema or __type) to retrieve information about the API’s structure, including available types, fields, queries, mutations, and their relationships. This capability is powerful for developers to explore and document APIs but poses a security risk if left enabled in production, as attackers can use it to map out the entire API structure and identify potential attack vectors.
Option A ("A technique for testing the compatibility of the GraphQL API with other systems"):
Incorrect, as introspection is about schema discovery, not compatibility testing.
Option B ("A technique for testing the performance of the GraphQL API"): Incorrect, as performance testing involves load or stress testing, not schema exploration.
Option C ("A technique for discovering the structure of the GraphQL API"): Correct, as introspection is specifically designed to expose the API’s schema and structure.
Option D ("A technique for testing the security of the GraphQL API"): Incorrect, as security testing is a separate process; introspection itself is a feature, not a security test.
The correct answer is C, aligning with the CAP syllabus under "GraphQL Security" and "API Introspection."
Reference: SecOps Group CAP Documents – "GraphQL Fundamentals," "Introspection Risks," and "OWASP API Security Top 10" sections.
C
Explanation:
GraphQL Introspection is a built-in feature of GraphQL that allows clients to query the schema of a GraphQL API at runtime. This process involves sending introspection queries (e.g., __schema or __type) to retrieve information about the API’s structure, including available types, fields, queries, mutations, and their relationships. This capability is powerful for developers to explore and document APIs but poses a security risk if left enabled in production, as attackers can use it to map out the entire API structure and identify potential attack vectors.
Option A ("A technique for testing the compatibility of the GraphQL API with other systems"):
Incorrect, as introspection is about schema discovery, not compatibility testing.
Option B ("A technique for testing the performance of the GraphQL API"): Incorrect, as performance testing involves load or stress testing, not schema exploration.
Option C ("A technique for discovering the structure of the GraphQL API"): Correct, as introspection is specifically designed to expose the API’s schema and structure.
Option D ("A technique for testing the security of the GraphQL API"): Incorrect, as security testing is a separate process; introspection itself is a feature, not a security test.
The correct answer is C, aligning with the CAP syllabus under "GraphQL Security" and "API Introspection."
Reference: SecOps Group CAP Documents – "GraphQL Fundamentals," "Introspection Risks," and "OWASP API Security Top 10" sections.
Question #54
The application is vulnerable to Cross-Site Scripting.
Which of the following exploitation is NOT possible at all?
- A . Steal the user’s session identifier stored on a non HttpOnly cookie
- B . Steal the contents from the web page
- C . Steal the contents from the application’s database
- D . Steal the contents from the user’s keystrokes using keyloggers
Correct Answer: C
C
Explanation:
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."
Reference: SecOps Group CAP Documents – "OWASP Top 10," "Cross-Site Scripting (XSS)," and "Client-Side Attack Vectors" sections.
C
Explanation:
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."
Reference: SecOps Group CAP Documents – "OWASP Top 10," "Cross-Site Scripting (XSS)," and "Client-Side Attack Vectors" sections.
Question #55
Scan the code below and identify the vulnerability which is the most applicable for this scenario.
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<meta name="description" content="xss">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/4.1.1/css/bootstrap.min.css" integrity="sha384-WskhaSGFgHYWDcbwN70/dfYBj47jz9qbsMId/iRN3ewGhXQFZCSftd1LZCfmhktB" crossorigin="anonymous">
<link rel="shortcut icon" href="/favicon.ico">
<link charset="utf-8" media="all" type="text/css" href="/static/css/main.css" rel="stylesheet">
<script type="text/javascript"
src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
- A . SQL Injection
- B . Type Juggling
- C . Component with a Known Vulnerability
- D . Server-Side Request Forgery
Correct Answer: C
C
Explanation:
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)."
Reference: SecOps Group CAP Documents – "Third-Party Component Security," "Software Supply Chain Security," and "OWASP Top 10" sections.
C
Explanation:
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)."
Reference: SecOps Group CAP Documents – "Third-Party Component Security," "Software Supply Chain Security," and "OWASP Top 10" sections.
Question #56
Based on the screenshot below, which of the following statements is true?
HTTP/1.1 200 OK
Accept-Ranges: bytes
Age: 359987
Cache-Control: max-age=604800
Content-Type: text/html; charset=UTF-8
Date: Fri, 02 Dec 2022 18:33:05 GMT
Expires: Fri, 09 Dec 2022 18:33:05 GMT
Last-Modified: Mon, 28 Nov 2022 14:33:18 GMT
Server: Microsoft-IIS/8.0
X-AspNet-Version: 2.0.50727
Vary: Accept-Encoding
X-Powered-By: ASP.NET
Content-Length: 1256
- A . The application is using an outdated server technology
- B . The application is disclosing the server version
- C . The application is disclosing the version of the framework used
- D . All of the above
Correct Answer: D
D
Explanation:
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."
Reference: SecOps Group CAP Documents – "Information Disclosure Prevention," "Server Hardening," and "OWASP Secure Headers Project" sections.
D
Explanation:
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."
Reference: SecOps Group CAP Documents – "Information Disclosure Prevention," "Server Hardening," and "OWASP Secure Headers Project" sections.
Question #57
Under the same-origin policy (also SOP), a web browser permits scripts contained in a web page to
access data in another web page, but only if both web pages have the same origin.
Which of the following pages are in the same origin as that of the below URL?
http://www.example.com/dir/page2.html
http://www.example.com/dir/other.html
http://www.example.com:81/dir/other.html
http://www.example.com/dir/other.html
http://en.example.com/dir/other.html
- A . 1 Only
- B . 1 and 2
- C . 1, 3 and 4
- D . None of the above
Correct Answer: A
A
Explanation:
The Same-Origin Policy (SOP) is a fundamental security mechanism in web browsers that restricts how a document or script loaded from one origin can interact with resources from another origin. An origin is defined by the combination of protocol, host, and port. Two pages have the same origin if their protocol (e.g., http://), host (e.g., www.example.com), and port (default is 80 for HTTP) match exactly. The given URL is http://www.example.com/dir/page2.html, which uses HTTP, host www.example.com, and the default port 80.
Option 1 ("http://www.example.com/dir/other.html"): Matches the protocol (http), host (www.example.com), and port (default 80), so it is in the same origin.
Option 2 ("http://www.example.com:81/dir/other.html"): Differs in port (81 vs. default 80), so it is a different origin.
Option 3 ("http://www.example.com/dir/other.html"): Identical to Option 1, matching protocol, host, and port, so it is in the same origin. However, since it’s a duplicate of Option 1 in the list, it doesn’t add a new page.
Option 4 ("http://en.example.com/dir/other.html"): Differs in host (en.example.com vs.
www.example.com), so it is a different origin.
Since the question asks which pages are in the same origin, and only Option 1 (and its duplicate Option 3) matches, the correct answer is A ("1 Only"), considering unique pages. The CAP syllabus covers SOP under "Client-Side Security" and "Cross-Origin Resource Sharing (CORS)."
Reference: SecOps Group CAP Documents – "Same-Origin Policy," "Browser Security Models," and "OWASP Client-Side Security" sections.
A
Explanation:
The Same-Origin Policy (SOP) is a fundamental security mechanism in web browsers that restricts how a document or script loaded from one origin can interact with resources from another origin. An origin is defined by the combination of protocol, host, and port. Two pages have the same origin if their protocol (e.g., http://), host (e.g., www.example.com), and port (default is 80 for HTTP) match exactly. The given URL is http://www.example.com/dir/page2.html, which uses HTTP, host www.example.com, and the default port 80.
Option 1 ("http://www.example.com/dir/other.html"): Matches the protocol (http), host (www.example.com), and port (default 80), so it is in the same origin.
Option 2 ("http://www.example.com:81/dir/other.html"): Differs in port (81 vs. default 80), so it is a different origin.
Option 3 ("http://www.example.com/dir/other.html"): Identical to Option 1, matching protocol, host, and port, so it is in the same origin. However, since it’s a duplicate of Option 1 in the list, it doesn’t add a new page.
Option 4 ("http://en.example.com/dir/other.html"): Differs in host (en.example.com vs.
www.example.com), so it is a different origin.
Since the question asks which pages are in the same origin, and only Option 1 (and its duplicate Option 3) matches, the correct answer is A ("1 Only"), considering unique pages. The CAP syllabus covers SOP under "Client-Side Security" and "Cross-Origin Resource Sharing (CORS)."
Reference: SecOps Group CAP Documents – "Same-Origin Policy," "Browser Security Models," and "OWASP Client-Side Security" sections.
Question #58
Based on the below HTTP request, which of the following statements is correct?
POST /changepassword HTTP/2
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Cookie: JSESSIONID=38RB5ECV10785B53AF29816E92E2E50
Content-Length: 95
new_password=usher!@22&confirm_password=usher!@22
- A . The change password feature does not validate the user
- B . The change password feature uses basic authorization
- C . The change password feature is vulnerable to Cross-Site Request Forgery attack
- D . All of the above
Correct Answer: C
C
Explanation:
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)."
Reference: SecOps Group CAP Documents – "CSRF Prevention," "Session Management," and "OWASP Secure Coding Practices" sections.
C
Explanation:
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)."
Reference: SecOps Group CAP Documents – "CSRF Prevention," "Session Management," and "OWASP Secure Coding Practices" sections.
Question #59
In the context of the following JWT token, which of the following statement is true?
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.ey
JUYW1I1joiU2vjbB3ZiNo_mn0vNWT4G1-
ATqOTmo7rm70VI12WCdkMI_S1_bPg_G8
- A . eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 represents a JWT Signature.
- B . mn0vNWT4G1-ATqOTmo7rm70VI12WCdkMI_S1_bPg_G8 represents a JWT Signature.
- C . eyJUYW1I1joiU2vjbB3ZiNo represents a JWT Signature.
- D . None of the above.
Correct Answer: D
D
Explanation:
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."
Reference: SecOps Group CAP Documents – "JSON Web Tokens (JWT)," "Token Integrity," and "OWASP JWT Cheat Sheet" sections.
D
Explanation:
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."
Reference: SecOps Group CAP Documents – "JSON Web Tokens (JWT)," "Token Integrity," and "OWASP JWT Cheat Sheet" sections.
Question #60
A website administrator forgot to renew the TLS certificate on time and as a result, the application is now displaying a TLS error message. However, on closer inspection, it appears that the error is due to the TLS certificate expiry.
In the scenario described above, which of the following is correct?
- A . There is no urgency to renew the certificate as the communication is still over TLS
- B . There is an urgency to renew the certificate as the users of the website may get conditioned to ignore TLS warnings and therefore ignore a legitimate warning which could be a real Man-in-the-Middle attack
Correct Answer: B
B
Explanation:
This question is identical to Question 52, describing a scenario where a TLS certificate has expired, causing a TLS error message, and asking about the correct course of action. The analysis remains the same:
Option A ("There is no urgency to renew the certificate as the communication is still over TLS"): Incorrect. An expired TLS certificate invalidates the trust model, even if the connection technically uses TLS. Browsers will issue warnings, and users may bypass them, but the lack of a valid certificate compromises security, making renewal urgent.
Option B ("There is an urgency to renew the certificate as the users of the website may get conditioned to ignore TLS warnings and therefore ignore a legitimate warning which could be a real Man-in-the-Middle attack"): Correct. Repeated exposure to TLS warnings due to an expired certificate may desensitize users, increasing the risk that they ignore legitimate warnings from a Man-in-the-Middle (MitM) attack. Renewing the certificate promptly is essential to maintain security
and user trust.
The correct answer is B, aligning with the CAP syllabus under "TLS Configuration" and "Certificate Management."
Reference: SecOps Group CAP Documents – "TLS Security," "Certificate Expiry Management," and "OWASP Transport Layer Protection Cheat Sheet" sections.
B
Explanation:
This question is identical to Question 52, describing a scenario where a TLS certificate has expired, causing a TLS error message, and asking about the correct course of action. The analysis remains the same:
Option A ("There is no urgency to renew the certificate as the communication is still over TLS"): Incorrect. An expired TLS certificate invalidates the trust model, even if the connection technically uses TLS. Browsers will issue warnings, and users may bypass them, but the lack of a valid certificate compromises security, making renewal urgent.
Option B ("There is an urgency to renew the certificate as the users of the website may get conditioned to ignore TLS warnings and therefore ignore a legitimate warning which could be a real Man-in-the-Middle attack"): Correct. Repeated exposure to TLS warnings due to an expired certificate may desensitize users, increasing the risk that they ignore legitimate warnings from a Man-in-the-Middle (MitM) attack. Renewing the certificate promptly is essential to maintain security
and user trust.
The correct answer is B, aligning with the CAP syllabus under "TLS Configuration" and "Certificate Management."
Reference: SecOps Group CAP Documents – "TLS Security," "Certificate Expiry Management," and "OWASP Transport Layer Protection Cheat Sheet" sections.