CCNA Application Environment Configuration And Security Questions

Running a container with a read-only root filesystem (option A) prevents any writes to the container's filesystem layer, which blocks malware from dropping files, modifying binaries, or persisting changes. This is enforced by the container runtime (e.g., Docker, containerd) by mounting the root filesystem as read-only, typically using the `--read-only` flag. Even if an attacker gains code execution inside the container, they cannot alter system files or install tools, significantly reducing the blast radius of a compromise.

SAST (Static Application Security Testing) is essential in the build phase because it analyzes source code, bytecode, or binary code for security vulnerabilities without executing the program. Integrating SAST early in the DevSecOps pipeline allows developers to identify and remediate flaws like SQL injection, buffer overflows, or cross-site scripting before the code is compiled and deployed, aligning with the 'shift left' security principle.

Option B is correct because running a container with a non-root user and dropping all capabilities enforces the principle of least privilege. By default, containers run with a limited set of capabilities, but explicitly dropping all capabilities and using a non-root user ensures that even if the application is compromised, an attacker cannot escalate privileges or perform privileged operations. This aligns with container security best practices, such as those outlined in the Docker security documentation and the CIS Docker Benchmark.

Option A is correct because XXE attacks exploit the XML parser's ability to process external entities defined in a DTD. By disabling DTD processing entirely, the parser cannot resolve or fetch external resources, which neutralizes the primary vector for XXE injection. This is a standard security hardening step for XML parsers like libxml2, Xerces, or .NET's XmlReader, often achieved by setting properties such as `LIBXML_NOENT` to false or `XmlReaderSettings.DtdProcessing` to `Prohibit`.

These protocols are essential for authentication and authorization.

Option C is correct because a dedicated secrets management service (e.g., AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) provides encryption at rest and in transit, automatic rotation, fine-grained access control via IAM policies, and audit logging. This prevents secrets from being exposed in configuration files, environment dumps, or version control, which is essential for cloud-native applications that must adhere to the principle of least privilege and compliance standards like SOC 2 or PCI DSS.

Input validation and output encoding are the primary defenses against XSS because they prevent malicious scripts from being interpreted by the browser. Input validation rejects or sanitizes dangerous characters (e.g., <, >, &) at the point of entry, while output encoding (e.g., HTML entity encoding) ensures that any user-supplied data rendered in the page is treated as text, not executable code. This directly addresses the root cause of XSS—untrusted data being injected into the DOM.

Parameterized queries (prepared statements) and ORM frameworks that use parameter binding prevent SQL injection by separating SQL logic from data. Stored procedures with dynamic SQL can still be vulnerable. Input validation alone or escaping are not sufficient or can be bypassed.

A service mesh (e.g., Istio) provides automatic mTLS for inter-service communication without modifying application code. VPNs and SSH tunnels are not designed for microservice-to-microservice communication at scale. API gateways handle external traffic, not internal service-to-service.

Copying a private SSH key into a Docker image embeds the credential in one of the image's layers. Even if the key is deleted in a later layer, it remains accessible via `docker history` or by pulling the intermediate layers, directly exposing sensitive credentials to anyone who can access the image.

Option B (bcrypt) is correct because it is designed for password hashing with a cost factor to resist brute-force. Option A (MD5) is fast and insecure; Option C (SHA-256) is better but lacks inherent salting and iteration; Option D (Base64) is encoding, not hashing.

OAuth 2.0 with JWT bearer tokens and scoped permissions is the best choice because it provides a standardized, token-based authentication and authorization mechanism at the application layer. The JWT contains claims (e.g., issuer, subject, expiration, and scopes) that can be cryptographically verified by each microservice without requiring a centralized session store, enabling fine-grained, per-API authorization. This directly addresses the requirement to authenticate and authorize every API call within a defense-in-depth strategy.

Regenerating the session ID upon successful login (option A) is a critical defense against session fixation attacks, where an attacker forces a known session ID on a user before authentication. By issuing a new, server-generated session ID after login, the application ensures that any pre-authentication session ID controlled by an attacker becomes invalid. This practice is recommended by OWASP and aligns with RFC 6265 session management guidelines.

Input validation is a security control that ensures user-supplied data matches expected formats, types, lengths, and ranges before processing. By rejecting malformed input, it directly prevents injection attacks (e.g., SQL injection, XSS, command injection) where an attacker embeds malicious code within input fields. This aligns with OWASP's top application security risks and is a foundational defense-in-depth measure.

Private keys must be readable only by the owner (usually root or the application user). Permission 600 ensures only the owner can read and write the file, preventing unauthorized access.

Option A is correct because integrating vulnerability scanning into the pipeline ensures each image is scanned before deployment, and failing the build on excessive vulnerabilities prevents insecure images from reaching production. Option B (Harbor webhook) would block pulls but images are already in the registry; Option C (PodSecurity) cannot assess vulnerability severity; Option D (manual updates) is inconsistent and does not enforce policy.

A Web Application Firewall (WAF) operates at Layer 7 (application layer) of the OSI model and inspects HTTP/HTTPS traffic for malicious payloads. It uses a combination of signature-based detection, behavioral analysis, and rule sets (e.g., OWASP ModSecurity Core Rule Set) to filter out common web exploits such as SQL injection, cross-site scripting (XSS), and path traversal. By intercepting and blocking malicious requests before they reach the web application, a WAF provides a critical layer of defense without requiring changes to the application code.

Forensic acquisition requires write-blocking first, then using FTK Imager to create a forensic image, ensuring integrity with hash verification.

The INPUT chain has a default policy of DROP. Only traffic matching explicit ACCEPT rules is allowed. HTTP (port 80) is accepted from any source; SSH (port 22) is accepted only from 192.168.1.0/24; ICMP is accepted from any; all other traffic is logged and then dropped (due to default DROP).

Data encryption at rest and in transit is a fundamental requirement for protecting sensitive data. While right to audit is important for compliance, the primary direct security control for data handling is encryption. SLAs and indemnification address availability and liability, not data protection.

Option C is correct because a failure to validate the JWT's 'alg' header can allow an attacker to change the algorithm to 'none' or from an asymmetric algorithm (e.g., RS256) to a symmetric one (e.g., HS256), potentially bypassing signature verification. This vulnerability, known as a JWT algorithm confusion attack, is a critical security concern because it directly undermines the integrity and authenticity of the token, which is the core security mechanism for authentication in microservices.

An identity provider with continuous evaluation (e.g., conditional access policies) can re-authenticate users based on risk signals throughout a session. VPNs and firewalls provide network access but lack session-level authentication. NAC enforces policy at connection time, not continuously.

Firewall configuration: open console, create allow rule for RDP, ensure it's enabled, then set default block, and test.

Option B is correct because it addresses both SQL injection (via parameterized queries) and cross-site scripting (via output encoding). Option A (WAF) can be bypassed; Option C (HTTPS) only encrypts in transit; Option D (SIEM) only logs, not prevents.

Option A (Pre-commit hook with git-secrets) is correct because it scans code before commit, preventing secrets from entering the repository. Option B (DAST) tests running apps; Option C (SAST) analyzes source but often after commit; Option D (RASP) protects at runtime.

The policy explicitly allows s3:ListBucket on example-bucket. The Deny statement for secret-bucket applies to all S3 actions on that bucket. There is no Allow for Delete or Put on example-bucket, so those are implicitly denied.

POST is non-idempotent—multiple identical requests may result in different side effects (e.g., creating multiple resources). PUT is idempotent, GET is safe, DELETE is idempotent.

Software Composition Analysis (SCA) is the correct tool because it specifically analyzes open-source and third-party libraries (dependencies) for known vulnerabilities by cross-referencing them against databases like the National Vulnerability Database (NVD). In a CI/CD pipeline for a Java application, SCA tools (e.g., OWASP Dependency-Check, Snyk) scan build artifacts such as pom.xml or build.gradle to identify vulnerable components before deployment.

Option B is correct because the CSP includes 'unsafe-inline' in the script-src directive, which explicitly allows inline scripts. This bypasses the primary protection CSP offers against XSS, as an attacker can inject malicious JavaScript directly into the HTML (e.g., via a <script> tag or event handler) without violating the policy. The 'self' source only restricts external scripts to the same origin, but inline scripts remain permitted, leaving the application vulnerable to stored, reflected, or DOM-based XSS attacks.

Static application security testing (SAST) analyzes source code, bytecode, or binaries without executing the program, allowing developers to identify vulnerabilities such as buffer overflows, SQL injection, and cross-site scripting during the coding phase. Integrating SAST early in the SSDLC reduces the cost and effort of fixing security flaws by catching them before they reach later stages like testing or production.

Output encoding is the most direct mitigation for XSS, as it ensures user input is rendered as data, not executable code. Input validation and parameterized queries address other vulnerabilities, while secure cookies help with session hijacking.

These features are covered in identity and access management and data protection domains.

Option C is correct because cloud-native applications should rely on a dedicated secrets management service (e.g., AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) that encrypts secrets at rest and in transit, enforces fine-grained access policies via IAM, and supports automatic rotation. This approach decouples secrets from code and infrastructure, eliminating the risks of exposure through version control, logs, or misconfigured permissions.

The `-Indexes` option disables directory listing, preventing visitors from seeing the contents of a directory if no index file is present. `AllowOverride None` disables .htaccess overrides, and `Allow from all` permits access.

Event injection via malformed input (B) is a specific serverless security concern because AWS Lambda functions are triggered by events from sources like API Gateway, S3, or DynamoDB Streams. An attacker can craft malicious input that exploits the function's event-handling logic, leading to unintended execution paths or data corruption. This differs from traditional injection attacks because the event structure itself can be manipulated to bypass validation.

Option B is correct because the JWT library accepts tokens with the algorithm set to 'none' when the public key is not provided during verification. This allows an attacker to forge a JWT with the 'none' algorithm, bypassing signature verification entirely. The attack succeeds because the application fails to enforce a whitelist of allowed algorithms, as recommended by RFC 7518.

Predictable session IDs allow an attacker to guess or brute-force valid session tokens, leading to session hijacking. Session fixation requires the attacker to set a known session ID, not predict. CSRF and clickjacking exploit user actions, not session prediction.

Option A is correct because using the device's keychain/keystore provides encrypted storage. Option B (plain XML) is insecure; Option C (SQLite without encryption) exposes data; Option D (remote database only) prevents offline access and may not be feasible.

Options A (OAuth2 with scopes), C (Validate all input), and E (Proper error handling without stack traces) are correct. Option B (Disable rate limiting) lowers security. Option D (Use JSONP) introduces cross-origin risks.

Option A is correct because the second statement allows anonymous PUT without any IP restriction, meaning anyone can upload objects to the bucket. Option B is incorrect because the GET action is restricted to the specified IP range. Options C and D are not indicated by the policy.

Code signing uses a digital signature (typically RSA or ECDSA) to bind the publisher's identity to the code. The primary purpose is to verify both the integrity (the code has not been tampered with) and the authenticity (the code comes from a trusted source) before deployment. This is achieved by hashing the code and signing the hash with the publisher's private key; the recipient verifies the signature using the publisher's public certificate.

Parameterized queries (prepared statements) separate SQL logic from user data by using placeholders (e.g., `?` in MySQLi or `:param` in PDO). The database driver automatically escapes the input values, ensuring they are treated as data, not executable code. This directly prevents SQL injection because the query structure is fixed before user input is bound.

Running a container as a non-root user with dropped capabilities is the most secure approach because it follows the principle of least privilege. By default, containers run as root, which grants unnecessary kernel capabilities that could be exploited for privilege escalation. Setting a non-root user and using `--cap-drop=ALL` with selective `--cap-add` ensures the application retains only required permissions, reducing the attack surface without breaking functionality.

Threat modeling identifies risks early; SAST automates code scanning for vulnerabilities; penetration testing validates security controls. Code signing ensures integrity but is not a core SSDLC process; continuous deployment is a DevOps practice, not a security activity.