Java Enterprise and Web Technologies

Printing unvalidated user input directly to the response output stream enables Reflected Cross-Site Scripting (XSS). Phishing is also possible through URL manipulation, and improper error handling could occur if exceptions are unhandled.

The code accepts a userID parameter directly from the request without validating whether the current user has permission to access that specific user's information. This allows any user to input any userID and view that user's details.

Access control is implemented only on the client-side using JavaScript and conditional rendering. An attacker can bypass this by directly calling /DeleteUsersAction URL or modifying the client-side code. Authorization must always be validated server-side.

The code uses Base64 encoding to obfuscate a redirect path. Base64 is a reversible encoding scheme, not encryption, representing a risky and weak attempt at securing sensitive parameters.

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.

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.

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.

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.

In J2EE web applications, the web.xml deployment descriptor file defines application-wide configurations including error pages. You specify error pages using elements that map exception types or HTTP error codes to custom display pages. Server.xml (A) is for server-level configuration in Tomcat, config.xml (B) is not a standard J2EE config file, and application.properties (D) is typically used for application-specific settings, not servlet container configurations.

The element in web.xml specifies session timeout in MINUTES, not smaller time units. This is defined in the servlet specification - the value represents the integer number of minutes before an inactive session is invalidated. Using milliseconds (A) or seconds (B) would make timeouts impractically large, and hours (D) is not the standard unit defined in the spec.

PUT, HEAD, and DELETE are all fully valid HTTP 1.1 methods. Therefore, the option stating 'All of the above are valid HTTP 1.1 methods' is correct.

HttpSession, ServletRequest, and ServletContext all define getAttribute() and setAttribute() methods to manage attributes within their respective scopes. ServletConfig only supports getInitParameter() and does not have attribute methods.

In J2EE 1.4 API, HttpSessionBindingEvent exists for session attribute binding/unbinding, but HttpSessionAttributeEvent does not exist. HttpSessionEvent, ServletRequestEvent, and ServletContextAttributeEvent are all valid listener event types in the specification.