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 #41
In the screenshot below, an attacker is attempting to exploit which vulnerability?
Request
POST /dashboard/userdata HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Firefox/107.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cookie: JSESSIONID=7576572ce167b5634ie646de967c759643d53031
Te: trailers
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 36
useragent=http://127.0.0.1/admin
Pretty Raw | Hex | php | curl | ln | Pretty
HTTP/1.1 200 OK
Date: Fri, 09 Dec 2022 11:42:27 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 12746
Connection: keep-alive
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Request-ID: 65403d71e8745d5e1fe205f44d531
Content-Length: 12746
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>
Admin Panel
</title>
- A . HTTP Desync Attack
- B . File Path Traversal Attack
- C . Open URL Redirection
- D . Server-Side Request Forgery
Correct Answer: D
D
Explanation:
The request is a POST to /dashboard/userdata with a parameter useragent=http://127.0.0.1/admin. The response is a 200 OK with an HTML page titled "Admin Panel," suggesting the server processed the request and returned content from http://127.0.0.1/admin. Let’s evaluate the vulnerability:
Analysis: The useragent parameter contains a URL (http://127.0.0.1/admin), and the server appears to fetch content from this URL, as indicated by the response containing the "Admin Panel" page. The URL 127.0.0.1 refers to the server’s localhost, meaning the server is making an internal request to itself based on user input. This is a hallmark of Server-Side Request Forgery (SSRF), where an attacker can trick the server into making requests to arbitrary locations, including internal systems (e.g., 127.0.0.1) or external sites. SSRF can lead to accessing internal resources (e.g., admin panels, metadata endpoints) or performing unauthorized actions.
Option A ("HTTP Desync Attack"): HTTP Desync attacks exploit discrepancies in how front-end and back-end servers interpret HTTP requests (e.g., smuggling requests). This scenario involves a straightforward POST request with no evidence of desynchronization or smuggling, so this is incorrect.
Option B ("File Path Traversal Attack"): File Path Traversal involves manipulating file paths (e.g.,
../../etc/passwd) to access unauthorized files on the server’s filesystem. The useragent parameter contains a URL, not a file path, and the response indicates a web request, not filesystem access, so this is incorrect.
Option C ("Open URL Redirection"): Open URL Redirection occurs when the server redirects the client to a user-supplied URL (e.g., via a Location header). The response here is a 200 OK, not a redirect (e.g., 302 Found), and the server is fetching content server-side, not redirecting the client, so this is incorrect.
Option D ("Server-Side Request Forgery"): Correct, as the server is making a request to http://127.0.0.1/admin based on the useragent parameter, indicating an SSRF vulnerability.
The correct answer is D, aligning with the CAP syllabus under "Server-Side Request Forgery (SSRF)"
and "OWASP Top 10 (A10:2021 – Server-Side Request Forgery)."
Reference: SecOps Group CAP Documents – "SSRF Vulnerabilities," "Input Validation for URLs," and "OWASP SSRF Prevention Cheat Sheet" sections.
D
Explanation:
The request is a POST to /dashboard/userdata with a parameter useragent=http://127.0.0.1/admin. The response is a 200 OK with an HTML page titled "Admin Panel," suggesting the server processed the request and returned content from http://127.0.0.1/admin. Let’s evaluate the vulnerability:
Analysis: The useragent parameter contains a URL (http://127.0.0.1/admin), and the server appears to fetch content from this URL, as indicated by the response containing the "Admin Panel" page. The URL 127.0.0.1 refers to the server’s localhost, meaning the server is making an internal request to itself based on user input. This is a hallmark of Server-Side Request Forgery (SSRF), where an attacker can trick the server into making requests to arbitrary locations, including internal systems (e.g., 127.0.0.1) or external sites. SSRF can lead to accessing internal resources (e.g., admin panels, metadata endpoints) or performing unauthorized actions.
Option A ("HTTP Desync Attack"): HTTP Desync attacks exploit discrepancies in how front-end and back-end servers interpret HTTP requests (e.g., smuggling requests). This scenario involves a straightforward POST request with no evidence of desynchronization or smuggling, so this is incorrect.
Option B ("File Path Traversal Attack"): File Path Traversal involves manipulating file paths (e.g.,
../../etc/passwd) to access unauthorized files on the server’s filesystem. The useragent parameter contains a URL, not a file path, and the response indicates a web request, not filesystem access, so this is incorrect.
Option C ("Open URL Redirection"): Open URL Redirection occurs when the server redirects the client to a user-supplied URL (e.g., via a Location header). The response here is a 200 OK, not a redirect (e.g., 302 Found), and the server is fetching content server-side, not redirecting the client, so this is incorrect.
Option D ("Server-Side Request Forgery"): Correct, as the server is making a request to http://127.0.0.1/admin based on the useragent parameter, indicating an SSRF vulnerability.
The correct answer is D, aligning with the CAP syllabus under "Server-Side Request Forgery (SSRF)"
and "OWASP Top 10 (A10:2021 – Server-Side Request Forgery)."
Reference: SecOps Group CAP Documents – "SSRF Vulnerabilities," "Input Validation for URLs," and "OWASP SSRF Prevention Cheat Sheet" sections.
Question #42
Which of the following is NOT a Server-Side attack?
- A . OS Code Injection
- B . Cross-Site Request Forgery
- C . SQL Injection
- D . Directory Traversal Attack
Correct Answer: B
B
Explanation:
Server-side attacks target vulnerabilities on the server, often involving code execution, data manipulation, or unauthorized access to server resources.
Let’s evaluate each option:
Option A ("OS Code Injection"): This is a server-side attack where an attacker injects operating system commands (e.g., via system() calls in PHP) to execute arbitrary code on the server, such as rm -rf /.
Option B ("Cross-Site Request Forgery"): CSRF is a client-side attack where an attacker tricks a user’s browser into making an unintended request to a server where the user is authenticated (e.g., submitting a form to transfer funds). The attack exploits the client’s trust in the user’s session, not a server-side vulnerability. Thus, it is not a server-side attack.
Option C ("SQL Injection"): This is a server-side attack where an attacker injects malicious SQL code into a query (e.g., ‘ OR ‘1’=’1) to manipulate the database, potentially extracting data or modifying records.
Option D ("Directory Traversal Attack"): This is a server-side attack where an attacker manipulates file paths (e.g., ../../etc/passwd) to access unauthorized files on the server outside the intended directory.
The correct answer is B, aligning with the CAP syllabus under "Client-Side vs. Server-Side Attacks"
and "CSRF Prevention."
Reference: SecOps Group CAP Documents – "CSRF Vulnerabilities," "Server-Side Attacks," and "OWASP Top 10 (A08:2021 – Software and Data Integrity Failures)" sections.
B
Explanation:
Server-side attacks target vulnerabilities on the server, often involving code execution, data manipulation, or unauthorized access to server resources.
Let’s evaluate each option:
Option A ("OS Code Injection"): This is a server-side attack where an attacker injects operating system commands (e.g., via system() calls in PHP) to execute arbitrary code on the server, such as rm -rf /.
Option B ("Cross-Site Request Forgery"): CSRF is a client-side attack where an attacker tricks a user’s browser into making an unintended request to a server where the user is authenticated (e.g., submitting a form to transfer funds). The attack exploits the client’s trust in the user’s session, not a server-side vulnerability. Thus, it is not a server-side attack.
Option C ("SQL Injection"): This is a server-side attack where an attacker injects malicious SQL code into a query (e.g., ‘ OR ‘1’=’1) to manipulate the database, potentially extracting data or modifying records.
Option D ("Directory Traversal Attack"): This is a server-side attack where an attacker manipulates file paths (e.g., ../../etc/passwd) to access unauthorized files on the server outside the intended directory.
The correct answer is B, aligning with the CAP syllabus under "Client-Side vs. Server-Side Attacks"
and "CSRF Prevention."
Reference: SecOps Group CAP Documents – "CSRF Vulnerabilities," "Server-Side Attacks," and "OWASP Top 10 (A08:2021 – Software and Data Integrity Failures)" sections.
Question #43
In the screenshot below, an attacker is attempting to exploit which vulnerability?
POST /dashboard HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) rv:107.0) Gecko/20100101 Firefox/107.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cookie: JSESSIONID=7576572ce164646de967c759643d53031
Te: trailers
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 81
xml_foo=<ENTITY example SYSTEM "file:///etc/passwd">]><foo>&example;</foo>
<!DOCTYPE foo [<!ENTITY example SYSTEM "file:///etc/passwd">]><foo>&example;</foo>
<foo>&example;</foo>
<title>Project Meeting</title>
<time>1200</time>
<location>changed example</location>
</body>
- A . Path Traversal Attack
- B . Server Side Template Injection
- C . XML Bomb Attack
- D . XML External Entity Attack
Correct Answer: D
D
Explanation:
The request is a POST to /dashboard with a payload containing XML data, specifically an xml_foo parameter with a <!DOCTYPE> declaration and an XML entity (<!ENTITY example SYSTEM "file:///etc/passwd">).
Let’s analyze the vulnerability:
The payload defines an XML External Entity (XXE) with <!ENTITY example SYSTEM "file:///etc/passwd">, which instructs the XML parser to fetch the contents of /etc/passwd (a sensitive system file) and include it in the &example; reference. The XML then includes <foo>&example;</foo>, which would expand to the contents of /etc/passwd if the parser processes the entity.
This is a classic XML External Entity (XXE) Attack, where an attacker exploits an XML parser’s ability to process external entities to access unauthorized resources (e.g., local files, internal network services) or cause denial-of-service. If the application’s XML parser is misconfigured to allow external entity resolution, this attack can disclose sensitive data like /etc/passwd.
Option A ("Path Traversal Attack"): Incorrect. Path Traversal involves manipulating file paths (e.g.,
../../etc/passwd) to access unauthorized files. While the attack aims to access /etc/passwd, it does so via XML entity resolution, not path traversal.
Option B ("Server Side Template Injection"): Incorrect. SSTI (Server-Side Template Injection) involves injecting template expressions (e.g., {{7*7}}) into a server-side template engine. The payload here is XML, not a template expression, and targets XML parsing, not a template engine.
Option C ("XML Bomb Attack"): Incorrect. An XML Bomb (or Billion Laughs attack) involves recursive entity expansion to cause denial-of-service (e.g., <!ENTITY a "&b;&b;"> <!ENTITY b "lol">), leading to exponential growth in memory usage. This payload defines a single external entity to fetch a file, not a recursive expansion, so it’s not an XML Bomb.
Option D ("XML External Entity Attack"): Correct, as the payload exploits XXE by defining an external entity to access /etc/passwd.
The correct answer is D, aligning with the CAP syllabus under "XML External Entity (XXE) Attacks" and "OWASP Top 10 (A04:2021 – Insecure Design)."
Reference: SecOps Group CAP Documents – "XXE Vulnerabilities," "XML Parsing Security," and "OWASP XXE Prevention Cheat Sheet" sections.
D
Explanation:
The request is a POST to /dashboard with a payload containing XML data, specifically an xml_foo parameter with a <!DOCTYPE> declaration and an XML entity (<!ENTITY example SYSTEM "file:///etc/passwd">).
Let’s analyze the vulnerability:
The payload defines an XML External Entity (XXE) with <!ENTITY example SYSTEM "file:///etc/passwd">, which instructs the XML parser to fetch the contents of /etc/passwd (a sensitive system file) and include it in the &example; reference. The XML then includes <foo>&example;</foo>, which would expand to the contents of /etc/passwd if the parser processes the entity.
This is a classic XML External Entity (XXE) Attack, where an attacker exploits an XML parser’s ability to process external entities to access unauthorized resources (e.g., local files, internal network services) or cause denial-of-service. If the application’s XML parser is misconfigured to allow external entity resolution, this attack can disclose sensitive data like /etc/passwd.
Option A ("Path Traversal Attack"): Incorrect. Path Traversal involves manipulating file paths (e.g.,
../../etc/passwd) to access unauthorized files. While the attack aims to access /etc/passwd, it does so via XML entity resolution, not path traversal.
Option B ("Server Side Template Injection"): Incorrect. SSTI (Server-Side Template Injection) involves injecting template expressions (e.g., {{7*7}}) into a server-side template engine. The payload here is XML, not a template expression, and targets XML parsing, not a template engine.
Option C ("XML Bomb Attack"): Incorrect. An XML Bomb (or Billion Laughs attack) involves recursive entity expansion to cause denial-of-service (e.g., <!ENTITY a "&b;&b;"> <!ENTITY b "lol">), leading to exponential growth in memory usage. This payload defines a single external entity to fetch a file, not a recursive expansion, so it’s not an XML Bomb.
Option D ("XML External Entity Attack"): Correct, as the payload exploits XXE by defining an external entity to access /etc/passwd.
The correct answer is D, aligning with the CAP syllabus under "XML External Entity (XXE) Attacks" and "OWASP Top 10 (A04:2021 – Insecure Design)."
Reference: SecOps Group CAP Documents – "XXE Vulnerabilities," "XML Parsing Security," and "OWASP XXE Prevention Cheat Sheet" sections.
Question #44
Which of the following HTTP response header prevents the client from caching the HTTP response in the most secure manner?
- A . Cache-Control: no-cache, no-store
- B . Secure-Cache: Enabled
- C . Cache-Control: Private
- D . Content-Security-Policy: no-cache, no-store
Correct Answer: A
A
Explanation:
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."
Reference: SecOps Group CAP Documents – "HTTP Caching Security," "Cache-Control Directives," and "OWASP Secure Headers Project" sections.
A
Explanation:
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."
Reference: SecOps Group CAP Documents – "HTTP Caching Security," "Cache-Control Directives," and "OWASP Secure Headers Project" sections.
Question #45
In the context of NoSQL injection, which of the following is correct?
Statement A: NoSQL databases provide looser consistency restrictions than traditional SQL databases. By requiring fewer relational constraints and consistency checks, NoSQL databases often offer performance and scaling benefits. Yet these databases are still potentially vulnerable to injection attacks, even if they aren’t using the traditional SQL syntax.
Statement B: NoSQL database calls are written in the application’s programming language, a custom API call, or formatted according to a common convention (such as XML, JSON, LINQ, etc).
- A . A is true, and B is false
- B . A is false, and B is true
- C . Both A and B are false
- D . Both A and B are true
Correct Answer: D
D
Explanation:
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."
Reference: SecOps Group CAP Documents – "NoSQL Injection Vulnerabilities," "Database Query Security," and "OWASP Top 10 (A03:2021 – Injection)" sections.
D
Explanation:
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."
Reference: SecOps Group CAP Documents – "NoSQL Injection Vulnerabilities," "Database Query Security," and "OWASP Top 10 (A03:2021 – Injection)" sections.
Question #46
While performing a security audit of a web application, you discovered an exposed docker-compose.yml file.
What is the significance of this file and what data can be found in it?
- A . The docker-compose.yml file is a YAML file that contains the application source code.
- B . The docker-compose.yml file is a YAML file that contains the server logs and user session information including but not limited to admin users.
- C . The docker-compose.yml file is a YAML file that is used to define the services, networks, and volumes required for a Docker application. It specifies the configuration and dependencies for all containers in the application, including their network settings and container volumes.
- D . The docker-compose.yml file is a YAML file that contains the configuration of load balancers and firewalls.
Correct Answer: C
C
Explanation:
A docker-compose.yml file is a YAML-formatted configuration file used with Docker Compose, a tool
for defining and running multi-container Docker applications. Its primary significance lies in orchestrating the deployment of Docker containers by specifying services (e.g., web server, database), networks (e.g., internal communication), and volumes (e.g., persistent storage). An exposed docker-compose.yml file poses a security risk because it may reveal sensitive configuration details, such as service names, ports, environment variables (e.g., database credentials), and network settings, which attackers could exploit to target the application.
Option A ("The docker-compose.yml file is a YAML file that contains the application source code"):
Incorrect, as this file defines configuration and orchestration, not source code.
Option B ("The docker-compose.yml file is a YAML file that contains the server logs and user session information…"): Incorrect, as logs and session data are stored elsewhere (e.g., in container logs or databases), not in docker-compose.yml.
Option C ("The docker-compose.yml file is a YAML file that is used to define the services, networks, and volumes…"): Correct, as it accurately describes the file’s purpose and content, including configuration and dependencies, which are critical for Docker applications.
Option D ("The docker-compose.yml file is a YAML file that contains the configuration of load balancers and firewalls"): Incorrect, as it focuses only on load balancers and firewalls, which are specific components and not the primary focus of the file.
The correct answer is C, aligning with the CAP syllabus under "Container Security" and "Configuration Management."
Reference: SecOps Group CAP Documents – "Docker Security," "Container Orchestration," and "OWASP Application Security Verification Standard (ASVS)" sections.
C
Explanation:
A docker-compose.yml file is a YAML-formatted configuration file used with Docker Compose, a tool
for defining and running multi-container Docker applications. Its primary significance lies in orchestrating the deployment of Docker containers by specifying services (e.g., web server, database), networks (e.g., internal communication), and volumes (e.g., persistent storage). An exposed docker-compose.yml file poses a security risk because it may reveal sensitive configuration details, such as service names, ports, environment variables (e.g., database credentials), and network settings, which attackers could exploit to target the application.
Option A ("The docker-compose.yml file is a YAML file that contains the application source code"):
Incorrect, as this file defines configuration and orchestration, not source code.
Option B ("The docker-compose.yml file is a YAML file that contains the server logs and user session information…"): Incorrect, as logs and session data are stored elsewhere (e.g., in container logs or databases), not in docker-compose.yml.
Option C ("The docker-compose.yml file is a YAML file that is used to define the services, networks, and volumes…"): Correct, as it accurately describes the file’s purpose and content, including configuration and dependencies, which are critical for Docker applications.
Option D ("The docker-compose.yml file is a YAML file that contains the configuration of load balancers and firewalls"): Incorrect, as it focuses only on load balancers and firewalls, which are specific components and not the primary focus of the file.
The correct answer is C, aligning with the CAP syllabus under "Container Security" and "Configuration Management."
Reference: SecOps Group CAP Documents – "Docker Security," "Container Orchestration," and "OWASP Application Security Verification Standard (ASVS)" sections.
Question #47
Which of the following is considered as a safe password?
- A . Monday@123
- B . abcdef
- C . Sq0Jh819%ak
- D . 1234567890
Correct Answer: C
C
Explanation:
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."
Reference: SecOps Group CAP Documents – "Password Management," "Authentication Security," and "OWASP Secure Coding Guidelines" sections.
C
Explanation:
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."
Reference: SecOps Group CAP Documents – "Password Management," "Authentication Security," and "OWASP Secure Coding Guidelines" sections.
Question #48
Based on the below-mentioned code snippet, the ‘filename’ variable is vulnerable to which of the following attacks?
import os
filename = input("Enter the file name:")
path = "/var/www/html/files/" + filename
content = ""
with open(path, ‘r’) as file:
content = file.read()
print("File content:n", content)
- A . Path Traversal
- B . Remote Code Execution
- C . Both A and B
- D . None of the above
Correct Answer: A
A
Explanation:
The code snippet is a Python script that takes user input for a filename, constructs a path by concatenating it with /var/www/html/files/, reads the file content, and prints it. The vulnerability arises because the filename variable is directly used in the path without sanitization or validation, allowing an attacker to manipulate it.
Path Traversal Vulnerability: An attacker can input a value like ../../etc/passwd to navigate outside the intended /var/www/html/files/ directory and access sensitive system files (e.g., /etc/passwd). Since the open() function will attempt to access the resulting path, this is a clear case of Path Traversal if the application runs with sufficient permissions.
Remote Code Execution (RCE): RCE would require the ability to execute arbitrary code, which is not directly possible here. The script only reads files, not executes them, unless the file contains executable code and the server interprets it (e.g., a PHP file on a web server), but this is not implied by the code alone.
Option A ("Path Traversal"): Correct, as the lack of input validation makes the code vulnerable to Path Traversal attacks.
Option B ("Remote Code Execution"): Incorrect, as the code does not execute the file content; it only reads it.
Option C ("Both A and B"): Incorrect, as RCE is not applicable here.
Option D ("None of the above"): Incorrect, as Path Traversal is a valid vulnerability.
The correct answer is A, aligning with the CAP syllabus under "Path Traversal Attacks" and "Input Validation."
Reference: SecOps Group CAP Documents – "Path Traversal Vulnerabilities," "Input Sanitization," and "OWASP Top 10 (A05:2021 – Security Misconfiguration)" sections.
A
Explanation:
The code snippet is a Python script that takes user input for a filename, constructs a path by concatenating it with /var/www/html/files/, reads the file content, and prints it. The vulnerability arises because the filename variable is directly used in the path without sanitization or validation, allowing an attacker to manipulate it.
Path Traversal Vulnerability: An attacker can input a value like ../../etc/passwd to navigate outside the intended /var/www/html/files/ directory and access sensitive system files (e.g., /etc/passwd). Since the open() function will attempt to access the resulting path, this is a clear case of Path Traversal if the application runs with sufficient permissions.
Remote Code Execution (RCE): RCE would require the ability to execute arbitrary code, which is not directly possible here. The script only reads files, not executes them, unless the file contains executable code and the server interprets it (e.g., a PHP file on a web server), but this is not implied by the code alone.
Option A ("Path Traversal"): Correct, as the lack of input validation makes the code vulnerable to Path Traversal attacks.
Option B ("Remote Code Execution"): Incorrect, as the code does not execute the file content; it only reads it.
Option C ("Both A and B"): Incorrect, as RCE is not applicable here.
Option D ("None of the above"): Incorrect, as Path Traversal is a valid vulnerability.
The correct answer is A, aligning with the CAP syllabus under "Path Traversal Attacks" and "Input Validation."
Reference: SecOps Group CAP Documents – "Path Traversal Vulnerabilities," "Input Sanitization," and "OWASP Top 10 (A05:2021 – Security Misconfiguration)" sections.
Question #49
Which of the following Google Dorks can be used for finding directory listing on victim-app.com?
- A . intitle:"Index of" site:victim-app.com
- B . intext:"Index of" site:victim-app.com
- C . Both A and B
- D . None of the above
Correct Answer: C
C
Explanation:
Google Dorks are advanced search operators used to find specific information or vulnerabilities on the web. Directory listing vulnerabilities occur when a web server exposes the contents of a directory (e.g., file names, paths) due to misconfiguration. The operators intitle: and intext: are used to search for specific terms in the title or body of web pages, respectively, combined with site: to limit the search to a specific domain.
Option A ("intitle:’Index of’ site:victim-app.com"): Correct, as intitle:"Index of" targets pages with "Index of" in the title, a common indicator of directory listings, and site:victim-app.com restricts the search to that domain.
Option B ("intext:’Index of’ site:victim-app.com"): Correct, as intext:"Index of" searches for "Index of" within the page content, another reliable indicator of directory listings, combined with the domain restriction.
Option C ("Both A and B"): Correct, as both intitle: and intext: can effectively identify directory listings, making this the most comprehensive answer.
Option D ("None of the above"): Incorrect, as both A and B are valid Google Dorks for this purpose. The correct answer is C, aligning with the CAP syllabus under "Reconnaissance Techniques" and "Google Dorking."
Reference: SecOps Group CAP Documents – "Information Gathering," "Google Hacking," and "OWASP Testing Guide" sections.
C
Explanation:
Google Dorks are advanced search operators used to find specific information or vulnerabilities on the web. Directory listing vulnerabilities occur when a web server exposes the contents of a directory (e.g., file names, paths) due to misconfiguration. The operators intitle: and intext: are used to search for specific terms in the title or body of web pages, respectively, combined with site: to limit the search to a specific domain.
Option A ("intitle:’Index of’ site:victim-app.com"): Correct, as intitle:"Index of" targets pages with "Index of" in the title, a common indicator of directory listings, and site:victim-app.com restricts the search to that domain.
Option B ("intext:’Index of’ site:victim-app.com"): Correct, as intext:"Index of" searches for "Index of" within the page content, another reliable indicator of directory listings, combined with the domain restriction.
Option C ("Both A and B"): Correct, as both intitle: and intext: can effectively identify directory listings, making this the most comprehensive answer.
Option D ("None of the above"): Incorrect, as both A and B are valid Google Dorks for this purpose. The correct answer is C, aligning with the CAP syllabus under "Reconnaissance Techniques" and "Google Dorking."
Reference: SecOps Group CAP Documents – "Information Gathering," "Google Hacking," and "OWASP Testing Guide" sections.
Question #50
In the context of the Race Condition vulnerability, which of the following statements is true?
- A . A situation that occurs when two threads access the same resource at the same time.
- B . A situation that occurs when two threads access different resources at the same time.
- C . A situation that occurs when a single thread unpredictably accesses two resources.
- D . A situation that occurs when a single thread predictably accesses two resources.
Correct Answer: A
A
Explanation:
A Race Condition vulnerability occurs in multi-threaded or multi-process applications when two or more threads access a shared resource concurrently, and the outcome depends on the non-deterministic order of their execution. This can lead to inconsistent states or security issues, such as privilege escalation or data corruption, if the access is not properly synchronized (e.g., using locks or semaphores). The classic definition focuses on concurrent access to the same resource.
Option A ("A situation that occurs when two threads access the same resource at the same time"): Correct, as this accurately describes a race condition where the lack of synchronization on a shared resource (e.g., a file, variable, or database entry) can lead to unpredictable behavior.
Option B ("A situation that occurs when two threads access different resources at the same time"): Incorrect, as race conditions specifically involve contention over the same resource, not different ones.
Option C ("A situation that occurs when a single thread unpredictably accesses two resources"): Incorrect, as race conditions require multiple threads or processes; a single thread’s behavior is not a race condition.
Option D ("A situation that occurs when a single thread predictably accesses two resources"): Incorrect, as predictability negates the race condition concept, and it still involves only one thread. The correct answer is A, aligning with the CAP syllabus under "Race Condition Vulnerabilities" and "Multi-Threaded Security."
Reference: SecOps Group CAP Documents – "Concurrency Issues," "Race Conditions," and "OWASP Secure Coding Practices" sections.
A
Explanation:
A Race Condition vulnerability occurs in multi-threaded or multi-process applications when two or more threads access a shared resource concurrently, and the outcome depends on the non-deterministic order of their execution. This can lead to inconsistent states or security issues, such as privilege escalation or data corruption, if the access is not properly synchronized (e.g., using locks or semaphores). The classic definition focuses on concurrent access to the same resource.
Option A ("A situation that occurs when two threads access the same resource at the same time"): Correct, as this accurately describes a race condition where the lack of synchronization on a shared resource (e.g., a file, variable, or database entry) can lead to unpredictable behavior.
Option B ("A situation that occurs when two threads access different resources at the same time"): Incorrect, as race conditions specifically involve contention over the same resource, not different ones.
Option C ("A situation that occurs when a single thread unpredictably accesses two resources"): Incorrect, as race conditions require multiple threads or processes; a single thread’s behavior is not a race condition.
Option D ("A situation that occurs when a single thread predictably accesses two resources"): Incorrect, as predictability negates the race condition concept, and it still involves only one thread. The correct answer is A, aligning with the CAP syllabus under "Race Condition Vulnerabilities" and "Multi-Threaded Security."
Reference: SecOps Group CAP Documents – "Concurrency Issues," "Race Conditions," and "OWASP Secure Coding Practices" sections.