CCNA Cissp Software Security Questions

Static Application Security Testing (SAST) analyzes source code, bytecode, or binary code for security vulnerabilities without executing the program. It operates by scanning the codebase for known patterns, such as SQL injection or buffer overflow, using techniques like data flow analysis and taint tracking. This white-box approach identifies issues early in the Software Development Life Cycle (SDLC), making it the correct answer for testing that does not require runtime execution.

A Software Bill of Materials (SBOM) lists all components, libraries, and dependencies used in the software. It is essential for assessing supply chain risk and identifying known vulnerabilities.

The team is ignoring the risk of using components with known vulnerabilities, which is explicitly listed in the OWASP Top 10 (A06:2021). Even if a vulnerability has not been exploited yet, continuing to use a library with a known CVE (e.g., a remote code execution flaw in an older version of Log4j) exposes the application to potential attacks once exploit code becomes public. The decision based on 'wide usage' and 'no exploitation so far' is a fallacy, as threat actors often target widely deployed libraries precisely because of their large attack surface.

Detailed error messages can leak sensitive information. Production systems should show generic messages to users and log detailed errors for administrators.

STRIDE is a threat modeling methodology developed by Microsoft that categorizes threats into six types: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. During the requirements gathering phase, STRIDE is commonly used to systematically identify and classify potential security threats against each system component, making it the correct choice for identifying threats like spoofing, tampering, and elevation of privilege.

A is correct because the outdated CMS with known vulnerabilities directly corresponds to OWASP A06:2021 – Vulnerable and Outdated Components. This category covers using software versions with unpatched security flaws, which attackers can exploit via public exploit databases or automated scanners.

Session fixation attacks occur when an attacker forces a user to use a known session ID. Regenerating the session ID after successful login (e.g., via `session_regenerate_id()` in PHP or `HttpServletRequest.changeSessionId()` in Java) ensures that the pre-authentication session ID is discarded and a new, unpredictable one is issued, breaking the attacker's control.

Industry-standard algorithms like AES-256 and SHA-256 are recommended, while MD5 and SHA-1 are deprecated due to weaknesses. Authenticated encryption (e.g., GCM) provides both confidentiality and integrity.

Error handling best practices dictate that generic error messages should be shown to users, while detailed errors (e.g., stack traces) should be logged internally to avoid information disclosure.

Exposing internal IP addresses in error messages is a classic example of a security misconfiguration (C). The web application is likely configured to output detailed error messages (e.g., stack traces or debug information) that include internal network details, which should be suppressed in production environments. This violates the principle of least information disclosure and is categorized under security misconfiguration because it stems from improper default or runtime settings.

Insecure Direct Object References (IDOR) occur when an application exposes direct references to internal objects (like user IDs) without proper access control checks. This allows an attacker to access other users' data by manipulating the ID.

Parameterized queries with prepared statements separate SQL logic from user input by sending the query structure to the database first, then binding input values as data parameters. This prevents the database from interpreting user input as executable SQL code, even if the input contains malicious characters. It is the only defense that completely eliminates the injection vector at the database interaction layer.

Parameterized queries (also known as prepared statements) separate SQL code from data by using placeholders (e.g., '?' in ODBC/JDBC or ':param' in Oracle) that are bound to user-supplied values at execution time. This ensures that input is always treated as data, never as executable SQL syntax, effectively neutralizing SQL injection regardless of the input content.

Account lockout after failed attempts reduces the feasibility of brute-force attacks, enforcing strong authentication mechanisms.

A Software Bill of Materials (SBOM) lists all components and dependencies, aiding vulnerability management and supply chain security.

SAST (Static Application Security Testing) analyzes source code, bytecode, or binary code for security vulnerabilities without executing the program. It operates by scanning the codebase for patterns known to be insecure (e.g., SQL injection via string concatenation) using techniques like data flow analysis, taint tracking, and pattern matching, all performed at rest.

B is correct because the vulnerability allows an attacker to access another user's private messages by simply changing a numeric ID in the URL, which is a classic example of Insecure Direct Object Reference (IDOR). This occurs when the application exposes a direct reference to an internal object (e.g., a database key) without proper access control checks, enabling unauthorized access to resources belonging to other users.

Output encoding is the practice of converting special characters (e.g., <, >, &, ") into their corresponding HTML entities (e.g., &lt; &gt; &amp; &quot;) before sending data to the browser. This ensures that any user-supplied data is treated as text, not executable code, thereby neutralizing injected scripts. It is the primary defense against stored, reflected, and DOM-based cross-site scripting (XSS) attacks because it breaks the parser's ability to interpret the data as active content.

Default administrator credentials are a classic security misconfiguration because they represent a failure to change vendor-supplied defaults before deployment. Attackers can easily guess or look up these credentials (e.g., admin:admin) to gain unauthorized access to the web server's management interface. This is explicitly listed in the OWASP Top 10 as a security misconfiguration (A05:2021).

Option A is correct because implementing integrity checks, such as digital signatures, ensures that serialized objects have not been tampered with during transit or storage. This prevents an attacker from modifying the serialized data to inject malicious objects, which is a primary vector for insecure deserialization attacks. By verifying the signature before deserialization, the application can reject any object that does not match the expected integrity hash.

Fail-secure ensures that when a system fails, it defaults to a secure state (e.g., denying access) rather than an insecure one.

Defense in depth uses multiple layers of security controls so that if one fails, others still provide protection.

Parameterized queries with prepared statements (Option B) are the definitive defense against SQL injection because they separate SQL logic from user-supplied data. The database engine compiles the query structure first, then binds input values as parameters, ensuring that malicious input cannot alter the intended SQL command. This approach is language-agnostic and works across all modern database interfaces (e.g., JDBC, PDO, ADO.NET).

Passwords should be salted and hashed using a strong, slow hash function like bcrypt, scrypt, or PBKDF2. Salting prevents rainbow table attacks.

Output encoding ensures user input is treated as data, and Content Security Policy (CSP) restricts sources of executable scripts. Input validation can help but is not as effective alone; whitelist validation is emphasized, but output encoding and CSP are primary defenses.

Output encoding (C) is the most secure approach because it neutralizes malicious scripts at the point of rendering, ensuring that user-controlled data is treated as text rather than executable code. For HTML contexts, HTML entity encoding (e.g., `&lt;script&gt;`) prevents the browser from interpreting injected tags, regardless of how the data was stored. This aligns with the defense-in-depth principle and is the primary mitigation for stored XSS as recommended by OWASP.

Integrity checks (e.g., digital signatures) ensure that serialized data has not been tampered with, preventing malicious objects from being deserialized.

A WAF filters, monitors, and blocks HTTP traffic to and from a web application. It helps protect against common web attacks like SQL injection, XSS, and CSRF by analyzing traffic at the application layer.

Tampering refers to the malicious modification of data. STRIDE's 'T' stands for Tampering.

Log4Shell is a remote code execution vulnerability in the Log4j library, an example of using vulnerable components (third-party libraries with known vulnerabilities).

IDOR occurs when an application exposes a direct reference to an internal object (e.g., database key) and does not verify the user's authorization to access that object.

Reviewing the SBOM, vulnerability scanning of dependencies, and vendor security assessments are key elements of third-party security evaluation. Code signing is a deployment control, not assessment; license compliance is legal but not security-specific.

STRIDE is a threat modeling framework developed by Microsoft that categorizes threats into six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

Defense in depth (B) is the correct principle because it involves implementing multiple layers of security controls (e.g., firewalls, intrusion detection systems, encryption, access controls) so that if one layer fails or is bypassed, other layers continue to provide protection, ensuring the system remains functional. This directly matches the scenario where the architect designs for continued operation despite component failure by layering controls.

Option A is correct because using industry-standard algorithms like AES-256 ensures the encryption is based on publicly vetted, mathematically robust ciphers that have undergone extensive cryptanalysis. Custom encryption algorithms are highly risky as they lack peer review and often contain subtle flaws that can be exploited, whereas AES-256 is a NIST-approved symmetric block cipher with a 256-bit key size that provides strong confidentiality for sensitive data.

Allowing weak passwords (e.g., 'password123') and not having multi-factor authentication (MFA) are broken authentication issues. Session timeout is a security control, not a vulnerability. Verbose error messages are a misconfiguration, and IDOR is an access control issue.

CSRF tokens are unique per request and validate the source, while SameSite cookies restrict cookie sending to same-site requests.

A Software Bill of Materials (SBOM) is a formal record containing the details and supply chain relationships of components used in building software.

Whitelist (allowlist) validation defines acceptable input patterns and rejects everything else, which is more effective than trying to block malicious patterns.

Reviewing the vendor's security certifications (e.g., SOC 2), assessing their incident response process, and requesting a Software Bill of Materials (SBOM) are key steps. License compliance is important but not directly security, and employee training is internal to the vendor but less critical than the others.

SSRF allows an attacker to induce the server to make requests to internal or external resources, bypassing firewalls and access controls.

Proper session management includes invalidating session tokens on logout and generating new tokens after authentication to prevent fixation.

Option A is correct because regenerating session tokens after login prevents session fixation attacks, where an attacker forces a known session ID on a user before authentication. This ensures that the session identifier used post-login is not the same as the one used pre-login, mitigating the risk of an attacker hijacking the authenticated session. This control directly addresses the issue of predictable session tokens by ensuring a fresh, unpredictable token is issued upon authentication.

Option D is correct because reflecting user-supplied data without proper encoding allows an attacker to inject arbitrary HTML/JavaScript that executes in the victim's browser. Output encoding (e.g., HTML entity encoding for context like <script> to &lt;script&gt;) neutralizes the injected script by treating it as data rather than executable code. This directly addresses the root cause of reflected XSS—failure to separate user input from executable content in the response.