Practice Free CAP Certified AppSec Practitioner Exam Exam Questions Answers With Explanation

Symmetric key encryption algorithms use the same key for both encryption and decryption, while asymmetric algorithms use a pair of keys (public and private). Let’s evaluate the options:

Option A ("RC4"): RC4 is a symmetric key encryption algorithm. It is a stream cipher that uses a single key to both encrypt and decrypt data, though it is considered insecure due to known cryptographic weaknesses (e.g., biases in the keystream).

Option B ("AES"): AES (Advanced Encryption Standard) is a symmetric key encryption algorithm. It uses a single key (e.g., 128, 192, or 256 bits) for both encryption and decryption, widely regarded as secure when properly implemented.

Option C ("DES"): DES (Data Encryption Standard) is a symmetric key encryption algorithm. It uses a 56-bit key for both encryption and decryption, but it is now considered insecure due to its small key size and vulnerability to brute-force attacks.

Option D ("RSA"): RSA (Rivest-Shamir-Adleman) is an asymmetric key encryption algorithm. It uses a public key to encrypt and a private key to decrypt, making it an asymmetric algorithm, not a symmetric one.

The correct answer is D, as RSA is the only asymmetric algorithm listed, aligning with the CAP syllabus under "Cryptography Fundamentals" and "Symmetric vs. Asymmetric Encryption."References: SecOps Group CAP Documents - "Symmetric Encryption Algorithms," "Asymmetric Encryption," and "OWASP Cryptographic Storage Cheat Sheet" sections.

SQL Injection (SQLi) occurs when an attacker injects malicious SQL code into a query by manipulating user input (e.g., ' OR '1'='1'), allowing unauthorized data access or manipulation. Let’s evaluate the defenses:

Option A ("Using a Web Application Firewall (WAF)"): A WAF can detect and block SQL injection attempts by filtering malicious patterns (e.g., ' OR '1'='1'), but it is not the primary defense. WAFs can be bypassed with sophisticated attacks (e.g., encoded payloads), and they are a secondary layer, not a fix for the root cause in the application code.

Option B ("Prepared Statements with Parameterized Queries"): Correct. Prepared statements with parameterized queries separate SQL code from user input by using placeholders (e.g., ? in SELECT * FROM users WHERE username = ?). The database engine handles the input as data, not executable code, preventing SQL injection. This is the industry-standard primary defense (recommended by OWASP and NIST) because it addresses the root cause by ensuring user input cannot alter the query structure.

Option C ("Use of NoSQL Database"): Switching to a NoSQL database (e.g., MongoDB) does not inherently prevent injection vulnerabilities. NoSQL databases can still be vulnerable to injection (e.g., MongoDB’s $where operator), and SQL injection applies to relational databases. This is not a defense against SQLi.

Option D ("Blacklisting Single Quote Character (‘)"): Blacklisting specific characters (e.g., ') attempts to block known malicious input, but it is ineffective as a primary defense. Attackers can bypass blacklists using alternate encodings (e.g., %27 for '), comments (e.g., --), or other techniques. Blacklisting is reactive and prone to evasion, unlike prepared statements.

The correct answer is B, aligning with the CAP syllabus under "SQL Injection Prevention" and "OWASP Top 10 (A03:2021 - Injection)."References: SecOps Group CAP Documents - "SQL Injection Defense," "Secure Coding Practices," and "OWASP SQL Injection Prevention Cheat Sheet" sections.

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."References: SecOps Group CAP Documents - "Information Disclosure Prevention," "Server Hardening," and "OWASP Secure Headers Project" sections.

Asymmetric key encryption (also known as public-key cryptography) uses a pair of keys: a public key for encryption and a private key for decryption (or vice versa for signing). Symmetric key encryption, on the other hand, uses the same key for both encryption and decryption. Let’s evaluate the options:

Option A ("AES"): AES (Advanced Encryption Standard) is a symmetric key encryption algorithm. It uses a single key (e.g., 128, 192, or 256 bits) for both encryption and decryption, making it a symmetric algorithm, not an asymmetric one.

Option B ("RSA"): RSA (Rivest-Shamir-Adleman) is an asymmetric key encryption algorithm. It uses a public key to encrypt data and a private key to decrypt it, making it a classic example of asymmetric cryptography.

Option C ("Diffie-Hellman"): Diffie-Hellman is an asymmetric key exchange algorithm. While it is primarily used for key exchange rather than direct encryption, it relies on asymmetric principles (public and private keys) to securely establish a shared secret, so it is considered part of asymmetric cryptography.

Option D ("DSA"): DSA (Digital Signature Algorithm) is an asymmetric algorithm used for digital signatures. It uses a pair of keys (public and private) for signing and verification, making it an asymmetric algorithm.

The correct answer is A, as AES is the only symmetric algorithm listed, aligning with the CAP syllabus under "Cryptography Fundamentals" and "Symmetric vs. Asymmetric Encryption."References: SecOps Group CAP Documents - "Cryptographic Algorithms," "Symmetric and Asymmetric Encryption," and "OWASP Cryptographic Storage Cheat Sheet" sections.

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."References: SecOps Group CAP Documents - "Information Gathering," "Google Hacking," and "OWASP Testing Guide" sections.

A JWT consists of three parts:Header,Payload, andSignature, 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."References: SecOps Group CAP Documents - "JSON Web Tokens (JWT)," "Token Integrity," and "OWASP JWT Cheat Sheet" sections.

A JSON Web Token (JWT) consists of three parts separated by dots (.):Header,Payload, andSignature. Each part is Base64Url-encoded. The given JWT is:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJUYW1I1joiU2vjbB3ZiNo_mn0vNWT4G1-ATqOTmo7rm70VI12WCdkMI_S1_bPg_G8

The first part (eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9) is the Header, which typically includes metadata like the algorithm (alg) and type (typ). Decoding it gives: {"alg":"HS256","typ":"JWT"}.

The second part (eyJUYW1I1joiU2vjbB3ZiNo_mn0vNWT4G1-ATqOTmo7rm70VI12WCdkMI_S1_bPg_G8) is the Payload, which contains claims (e.g., user data, expiration). The highlighted segment corresponds to this second part, making it the Payload. Decoding it (though incomplete due to truncation) would reveal claims in JSON format.

The third part (not fully shown) would be the Signature, used to verify the token’s integrity.

Option A ("The highlighted segment of the token represents a JWT Header"): Incorrect, as the highlighted segment is the second part, which is the Payload.

Option B ("The highlighted segment of the token represents a JWT Payload"): Correct, as the highlighted segment is the Payload portion of the JWT.

Option C ("Both A and B are correct"): Incorrect, as only B is correct.

Option D ("None of the above"): Incorrect, as B is correct.

The correct answer is B, aligning with the CAP syllabus under "JWT Security" and "Token-Based Authentication."

References: SecOps Group CAP Documents - "JSON Web Tokens (JWT)," "Authentication Security," and "OWASP JWT Cheat Sheet" sections.

The screenshot shows an HTTP POST request to /upload.php with a multipart/form-data payload, where the attacker uploads a file named malicious.php disguised as an image/jpeg but containing PHP code (). This indicates an attempt to exploit aFile Upload Vulnerability. Such vulnerabilities occur when an application allows users to upload files without proper validation or sanitization, enabling attackers to upload malicious scripts (e.g., PHP) that can be executed on the server. In this case, if the server executes the uploaded malicious.php, it could expose server information via phpinfo() or perform other malicious actions.

Option A ("HTTP Desync Attack") involves manipulating HTTP request pipelines, which is not relevant here as the request appears standard. Option B ("File Path Traversal Attack") involves accessing unauthorized files using ../, which is not evident in this request. Option D ("Server-Side Request Forgery") involves tricking the server into making unintended requests, which does not apply to file uploads. Thus, C is the correct answer, aligning with the CAP syllabus under "File Handling Security" and "OWASP Top 10 (A05:2021 - Security Misconfiguration)."References: SecOps Group CAP Documents - "File Upload Vulnerabilities," "Input Validation," and "OWASP Top 10" sections.

SAML (Security Assertion Markup Language) is an open standard for exchanging authentication and authorization data between parties, particularly in the context of single sign-on (SSO). It is based on XML and is widely used to enable secure web-based authentication and authorization across different domains. The correct full form isSecurity Assertion Markup Language, where "Assertion" refers to statements about a subject (e.g., identity, attributes), "Markup" indicates the XML-based structure, and "Language" denotes the defined syntax.

Option A ("Security Assertion Markup Language"): This is the correct and official full form of SAML as defined by OASIS (Organization for the Advancement of Structured Information Standards).

Option B ("Security Authorization Markup Language"): Incorrect, as "Authorization" is not part of the acronym; SAML focuses on both authentication and authorization assertions.

Option C ("Security Assertion Management Language"): Incorrect, as "Management" is not part of the acronym; SAML is about markup, not management.

Option D ("Secure Authentication Markup Language"): Incorrect, as "Secure" is not part of the acronym, and SAML covers more than just authentication.

The correct answer is A, aligning with the CAP syllabus under "Authentication and Authorization" and "Single Sign-On (SSO) Standards."References: SecOps Group CAP Documents - "SAML Overview," "Authentication Protocols," and "OWASP Identity Management" sections.

TLS (Transport Layer Security) certificates are validated by browsers to ensure secure communication. Browsers maintain a trusted store ofpublic keysfrom known Certifying Authorities (CAs), which are used to verify the digital signature of a TLS certificate presented by a server. This process involves checking the certificate’s signature against the CA’s public key to confirm its authenticity and validity. If the signature matches and other criteria (e.g., expiration, revocation) are met, the certificate is deemed valid.

Option A ("The browser contains the private key..."): Incorrect, as browsers do not contain private keys of CAs; private keys are kept secret by the CAs themselves.

Option B ("The browser contains the public key..."): Correct, as browsers use CA publickeys to validate certificates, enabling differentiation between valid and invalid TLS certificates.

Option C ("The browser contains both the public and private key..."): Incorrect, as browsers only store public keys, not private keys, for security reasons.

Option D ("The browser does not have any mechanism..."): Incorrect, as browsers have robust mechanisms (via CA public keys) to validate TLS certificates.

The correct answer is B, aligning with the CAP syllabus under "Secure Communication" and "TLS Configuration."References: SecOps Group CAP Documents - "TLS/SSL Security," "Certificate Validation," and "OWASP Cryptographic Practices" sections.

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 isAccess-Control-Allow-Origin, which specifies which origins are permitted to access the resource. However, among the provided options, the closest related header isAccess-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 apreflight 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."References: SecOps Group CAP Documents - "CORS Configuration," "Security Headers," and "OWASP Secure Headers Guide" sections.

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

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

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

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

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

The correct answer is B, aligning with the CAP syllabus under "Cross-Site Scripting (XSS)" and "Input Validation Best Practices."References: SecOps Group CAP Documents - "XSS Prevention," "Input Validation and Sanitization," and "OWASP XSS Prevention Cheat Sheet" sections.

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."References: SecOps Group CAP Documents - "Docker Security," "Container Orchestration," and "OWASP Application Security Verification Standard (ASVS)" sections.