Java Web Application Security and Input Validation

Option A handles all exceptions via Throwable to redirect to error.jsp. Option B catches HTTP 500 errors to redirect to the same page. Both are valid error-page configurations in web.xml. Option C is invalid because an error-page must specify either exception-type or error-code.

Session timeout is configured in web.xml within the session-config element. This is the standard deployment descriptor for Java web applications. Server.xml is for server-wide global settings, not application-specific session configuration.

Using unvalidated user input directly in a cookie value enables cookie manipulation attacks. Setting MaxAge to 3600 seconds creates a persistent cookie stored across sessions, which amplifies the attack surface compared to session cookies.

If an exception occurs before close() calls, resources leak. Proper Java resource management requires finally blocks or try-with-resources to guarantee cleanup regardless of exceptions.

HTTP PUT and DELETE can be disabled via web.xml configuration as shown in option A. Option B is also true as many servers disable them by default for security. E combines both correct statements.

Returning from finally blocks is dangerous because it discards any pending exceptions from try or catch blocks and creates confusing control flow. It also swallows the original return values.

If an exception occurs during transaction, closeConnection() is never called, causing resource leaks. Repeated failures exhaust connection pools, creating Denial of Service.

Passing an unvalidated user-controlled parameter directly to a FileInputStream allows directory traversal attacks (e.g., passing '../../etc/passwd'), leading to unauthorized information disclosure despite read-only OS privileges.

The AccessController class is used for Java security management. Statements a, b, and c are true: AccessController can mark code as privileged using doPrivileged(), decides access based on security policy, and can capture calling context via getContext(). Statement d is false - cryptographic hash computation is performed by classes like MessageDigest, not AccessController.

Subject.doAs() is the correct API that associates a Subject with the current thread of execution in Java authentication and authorization. It executes an action as that Subject. AccessController.checkPermission() checks permissions but doesn't associate subjects with threads. SecurityManager.checkAccess() checks thread access control, not subject association.

Option 2 is true: classes with identical fully qualified names loaded by different class loaders are treated as different types due to namespace isolation. Option 4 is also true: TrustManager specifically validates authentication credentials like X.509 certificates. Options 1 and 3 are false: type safety doesn't prevent all malicious code, and signed classes aren't automatically granted full access.

The correct command-line tool for managing keystores is 'keytool', not any of the listed options. securitymanager manages runtime security checks, policytool manages policy files, jarsigner signs JAR files, and keystore is not a tool but a file format/database type. Since the correct tool (keytool) isn't listed, 'None of the above' is the right choice.

Digital signatures work by creating a hash of the original document, then encrypting that hash with the signer's private key. This creates a fixed-size signature that can be verified by decrypting with the public key and comparing against a newly computed hash. The document itself isn't encrypted (options B, C, D) - digital signatures provide authenticity and integrity, not confidentiality.

Among the listed tools, only Fortify and FindBugs are static application security testing (SAST) tools designed for security code review. WebScarab, WebInspect, AppScan, and Nikto are dynamic scanners or proxies.

Struts 2 introduced built-in support for annotation-based validation using the @Validation annotation and its associated validator annotations, whereas older Struts 1.x versions relied on XML configurations.

All data originating from the client side—including parameters, query strings, cookies, and headers—can be easily manipulated by an attacker and must be thoroughly validated before use.

This is whitelist validation because it explicitly defines allowed characters (A-Z, a-z) using the pattern [^A-z] and rejects anything that doesn't match. Whitelist validation is more secure because it only permits known good characters, rejecting everything else as the code does with 'Invalid Input'.

This is blacklist validation because it explicitly removes specific dangerous characters (<, >, {, }, , [, ], ;, &) from the input. Blacklist validation attempts to filter out known bad patterns but is less secure than whitelist validation because attackers can use encoding or alternative characters not in the blacklist.

XSS prevention requires two complementary approaches: Input Validation (whitelist allowed characters/patterns) and Output Encoding (escape dynamic output based on context). These neutralize malicious scripts. Releasing resources, least privilege, and URL access control address different security concerns (resource leaks, privilege escalation, authorization).