Cookies are an essential part of any web application and can be used for a number of different purposes such as user authentication. A cookie is a small piece of data that is set by a web server's response that will be stored for a certain period of time on the client's computer. After a cookie has been set, all of the information within it will be sent in all subsequent requests to the cookie domain. Because of this, the information within a cookie is not secure and can be retrieved through a variety of attacks such as cross-site scripting (XSS) or man-in-the-middle attacks. As a result, it is important that the server does not set a cookie that contains excess or sensitive information about a user. This includes, but is not limited to, user names, passwords, password hashes, credit cards, and any personally identifiable information about the user.
Noncompliant Code Example
In this noncompliant code example, we can see that the servlet stores the user name in the cookie to identify the user for authentication purposes.
import java.util.ArrayList; import java.util.List; import javax.servlet.http.*; import com.insecure.model.UserDAO; import com.insecure.databeans.UserBean; public class InsecureServlet extends HttpServlet { private UserDAO userDAO; // ... private String login(HttpServletRequest request, HttpServletResponse response) { List<String> errors = new ArrayList<String>(); request.setAttribute("errors", errors); Â Â Â Â Â Â Â String username = request.getParameter("username"); char[] password = request.getParameter("password").toCharArray(); Â Â Â Â Â Â // Basic input validation if(!username.matches("[\\w]*") || !password.toString().matches("[\\w]*")) { errors.add("Incorrect user name or password format."); return "error.jsp"; } Â Â Â Â Â UserBean dbUser = this.userDAO.lookup(username); if(!dbUser.checkPassword(password)) { errors.add("Passwords do not match."); return "error.jsp"; } Â Â Â // Create a cookie that contains the username Cookie userCookie = new Cookie("username", username); // Create a cookie that contains the password Cookie passCookie = new Cookie("password", password); // Add the cookie information to the response that the client will receive response.addCookie(userCookie); response.addCookie(passCookie); // Clear password char array Arrays.fill(password, ' '); return "welcome.jsp"; } }
Note that the above noncompliant code example stores the user name and password within the cookie for authentication purposes. This particular code example is insecure because an attacker could possibly perform a cross-site scripting attack or sniff packets to find this information. Once the attacker finds this information, they have free reign to log in to the user's account. On the other hand, if the application only stored the user name within the cookie for authentication purposes, an attacker could still use the user name to forge their own cookie and bypass the authentication system.
Compliant Solution
The previous noncompliant example can be resolved by using the HttpSesssion
class within the javax.servlet.http
package ?to store user information as opposed to cookies. Since HttpSession
objects are server-side, it is impossible for an attacker to gain access to the session information directly through cross-site scripting or man-in-the-middle attacks. Instead, a session id is stored within the cookie to refer to the user's HttpSession
object stored on the server. As a result, the attacker must first gain access to the session id and only then do they have a chance of gaining access to a user's account details.
public class InsecureServlet extends HttpServlet { private UserDAO userDAO; // ... private String login(HttpServletRequest request) { List<String> errors = new ArrayList<String>(); request.setAttribute("errors", errors); String username = request.getParameter("username"); char[] password = request.getParameter("password").toCharArray(); // Basic input validation if(!username.matches("[\\w]*") || !password.toString().matches("[\\w]*")) { errors.add("Incorrect user name or password format."); return "error.jsp"; } UserBean dbUser = this.userDAO.lookup(username); if(!dbUser.checkPassword(password)) { errors.add("Passwords do not match."); return "error.jsp"; } HttpSession session = request.getSession(); // Invalidate old session id session.invalidate(); // Generate new session id session = request.getSession(true); // Set session timeout to one hour session.setMaxInactiveInterval(60*60); // Store user bean within the session session.setAttribute("user", dbUser.getUsername()); // Clear password char array Arrays.fill(password, ' '); return "welcome.jsp"; } }
This solution uses a session and not a cookie to store user information. Additionally, the current session is invalidated and a new session is created to avoid session fixation attacks as noted by The Open Web Application Security Project [OWASP 2009] . The timeout of the session has also been set to one hour to minimize the window that an attacker has to perform any a session hijacking attack.
Risk Assessment
Noncompliance may lead to sensitive information being stored within a cookie, which may be accessible via packet sniffing or cross-site scripting attacks.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
FIO14-J |
medium |
probable |
medium |
P8 |
L2 |
Bibliography
[OWASP 2009] Session Fixation in Java
[OWASP 2010] Cross-site Scripting
[Oracle 2010] javax.servlet.http Package API
The World Wide Web Security FAQ