Java / Servlet Interview Questions
Java Servlet is a server side technologies to extend the capability of web servers by providing support for dynamic response and data persistence.
Servlet technology was introduced to overcome the shortcomings of CGI technology.
- Servlet provide better performance that CGI in terms of processing time, memory utilization because servlets uses benefits of multithreading and for each request a new thread is created, that is faster than loading creating new Object for each request with CGI.
- Servlet is platform and system independent, the web application developed with Servlet can be run on any standard web container such as Tomcat, JBoss, Glassfish servers and on operating systems such as Windows, Linux, Unix, Solaris, Mac etc.
- Servlets are robust because container takes care of life cycle of servlet and we don?t need to worry about memory leaks, security, garbage collection etc.
- Servlets are easy to maintain and scalable.
No. The Remote client's hardware address cannot be retrieve from the servlet request.
Calling session.invalidate method logs out the user.
For Java EE 6 (Servlet 3.0) the setHttpOnly and setSecure methods can be used to protect HTTP Cookies.
For older Java versions, there are no API available to directly set the HttpOnly and Secure flags. The workaround is creating a custom SET-COOKIE header.
String sessionId = request.gerSession().getId(); Response.setHeader("SET-COOKIE", "JSESSIONID=" + sessionId + "; HttpOnly; Secure");
destroy() is part of servlet life cycle methods, it is used to kill the servlet instance. Servlet Engine is used to call destroy(). In case, if you call destroy method from service(), it just execute the code written in the destroy(), but it wont kill the servlet instance. destroy() will be called before killing the servlet instance by servlet engine.
out.println prints to the browser and System.out.println() prints to the server console.
The condition will be evaluated to false as JSTL suppresses NullPointerException.
getRemoteUser() returns the login of the users making this request if the user has been authenticated; returns null if the user is not authenticated.
isUserInRole() returns a boolean indicating whether the authenticated user is included in the specified role.
getUserPrincipal() returns a java.security.Principal object containing the name of the current authenticated user.
In Java EE, the component containers are responsible for providing application security. A container provides two types of security: declarative and programmatic.
Declarative security is the preferred method, which expresses application security requirements via configuration parameters found in the application servers web.xml configuration file. Also, Annotations can be used in the code.
In programmatic policy enforcements, to check authentication/authorization you may have to call isUserInRole() every time you need to execute a particular function. This is okay for small scale applications but not for large enterprise-scale applications.
The @ServletSecurity annotation provides an alternative mechanism for defining access control constraints for the whole servlet. These annotations provide an alternative mechanism for specifying security constraints declaratively by
The @DeclareRoles annotation is used by application to declare security roles. It can be specified on a class. The value of the DeclareRoles annotation is a list of security role names.
The @DenyAll annotation specifies that no security roles are allowed to invoke the specified method(s) - i.e that the methods are to be excluded from execution in the J2EE container.
The @PermitAll annotation specifies that all security roles are allowed to invoke the specified method(s) i.e that the specified method(s) are "unchecked". It can be specified on a class or on methods. Specifying it in the class means that it applies to all methods of the class. If specified at the method level, it only affects that method.
The @RolesAllowed annotation specifies the security roles permitted to access methods in an application. This annotation can be specified on a class or on one or more methods. When specified at the class level, the annotation applies to all methods in the class. When specified on a method, the annotation applies to that method only and overrides any values specified at the class level.
The @RunAs annotation is equivalent to the <run-as> element in the deployment descriptor and allows developers to run code under the specified role.
There are 4 main types.
- Basic username and password are sent in base64 in HTTP header, sent in cleartext so SSL is needed.
- Digest MD5 digest of credentials (hashed passwords ) are sent.
- Form-Based username/passwords are sent in POST body; need SSL.
- Certifcate-based User sends certificate to the server; very secure and enables Mutual authentication.
Message Certification: Mesage data is certified that it has not been modified since it was created by the source.
Message Encryption: Parts of a message/entire message may be encrypted during transmission. It is a good choice when data must be protected past the TLS termination point.
Tunnel Encryption: Unlike message protection, the entire data tunnel is protected. This includes all data and metadata sent between source and destination. Regardless of the encryption technique, some parts of the IP packet, like the source and destination addresses always remain unencrypted. All untrusted intermediaries will have access to some minimal unencrypted metadata like source/destination IP addresses. Without proper IP packet header information, TCP/IP packets cannot be routed properly, and communication over the internet is not possible.
Man in the middle (MITM) attacks: the attacker's proxy is inserted between the client and server to intercept the data. Compromised data may be disclosed or altered depending upon the attacker's goals and technical factors.
Weak cipher,
X.509 private certificate leakage: Private certificates are sensitive information. Unintended disclosure can cause a lot of problems like spoofing identity. Store certificates in a password protected PKCS12 keystone as a minimum protective measure.
Poor configuration: Avoid common mistakes like hardcoded and plaintext passwords, open ports, and incorrect firewall configuration. Run your web application server with restricted privileges and not as root or administrator.
Common web server infrastructure: SOAP services leverage existing web/web service infrastructure, so from a security perspective, IT Operations groups usually know how to configure web servers securely.
Dynamic service bindings: SOAP provides descriptive service bindings via WSDL documents. Binding include transport protocol information such as HTTPS. This is a benefit of SOAP over RESTful services, which don't provide any binding information unless it's manually created documentation.
Message centric: SOAP is a messaging standard, so there are a number of options for securing all or parts of SOAP messages; these decisions can be made independently of transport protocols like HTTPs.
Message centric: WS-Security provides 3 main mechanisms such as
- signing SOAP messages for ensuring integrity including non-repudiation,
- encrypting SOAP messages to ensuring confidentially, and
- attaching security tokens to messages to establish user identity.
Set the HttpOnly Flag on the Session ID.
