Java Enterprise and Web Technologies

EnterpriseSecurityException contains two types of messages - a log message for developers/sysadmins that may contain sensitive details, and a user message that is safe for end users. This separation prevents information leakage.

The login() method handles user authentication and can fail for various reasons (invalid credentials, locked account, etc.). When authentication fails, it throws a SecurityException, which is the appropriate exception type for security-related failures in the API hierarchy.

The correct method signature uses HttpServletResponse as the parameter since caching headers are set on the response object. The method is void because it performs an action (setting headers) rather than returning a value. Option B incorrectly uses HttpServletRequest, and options C and D have incorrect return types or exception declarations.

Cross Site Request Forgery (CSRF) prevention requires adding unpredictable tokens to requests that the server can verify. The addCSRFToken method is specifically designed for this purpose. Option A (encryption) and C (secure communication verification) address different security concerns, while D (content type) is about XSS prevention.

The isSecureRequest method performs two critical security checks: verifying SSL usage (HTTPS) and ensuring the HTTP method is POST. POST over HTTPS provides confidentiality and is the standard for secure form submissions. Options A and B are each partially correct but incomplete.

EnterpriseSecurityException contains two types of messages: a log message for developers/system administrators and a user message safe for display. This separation prevents exposing sensitive technical details to end users while maintaining audit trails. Options A and B are each partially correct.

The login method throws SecurityException when authentication fails or security violations occur during the login process. This is a standard exception type for security-related failures in Java security APIs, providing a clear indication of security-related issues.

Cache control headers must be set on the HttpServletResponse object, not the HttpServletRequest. The method returns void as it performs an action (setting headers) rather than returning a value. ServletException is not relevant to header operations, making option A the correct signature.

Preventing Cross Site Request Forgery requires associating requests with a unique, unpredictable, and user-specific token. The addCSRFToken method appends this token to URLs, verifying that the request originated from the authenticated user rather than an external site.

The isSecureRequest method performs comprehensive security validation by checking both if the request uses HTTPS (SSL/TLS encrypted channel) and if it's a POST method. This dual verification ensures sensitive operations only proceed over secure connections with appropriate HTTP methods.

EnterpriseSecurityException maintains two separate messages: a log message containing technical details for developers (written to log files, not shown to users) and a user message with sanitized, safe information appropriate for display to end users without exposing sensitive system details.

When part of the app uses a domain name but login uses IP (10.1.52.3), AppScan needs to know about both to test the complete application. Adding the domain to 'Additional servers and domains' allows AppScan to follow links and test all parts. Adding only the IP or changing code are incorrect approaches.

The injected payload contains %0d%0a (CRLF - carriage return + line feed) used to split HTTP responses. AppScan tests for HTTP Response Splitting by injecting these characters to attempt injecting arbitrary headers or splitting the response body. This can lead to cache poisoning, XSS, or other attacks. CRLF injection is the key indicator.

Parameter tracking ensures AppScan tests each unique page value separately. If you ignore or limit it, AppScan might only test one value and miss vulnerabilities on other pages.

.NET web services traditionally use SOAP, where parameters are embedded in the XML SOAP envelope. AppScan modifies these SOAP parameters to inject test payloads, not the HTTP-level GET/POST parameters or cookies.