...
In this non compliant code example, we can see that the servlet stores the user name in the cookie to identify the user for authentication purposes.
| Code Block | ||
|---|---|---|
| ||
import java.util.ArrayList; import java.util.List; import javax.servlet.http.*; import edu.cmu.insecure.model.UserDAO; import edu.cmu.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"); String password = request.getParameter("password"); Â Â Â Â Â Â // Basic input validation if(!username.matches("[\\w]*") || !password.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"; } Â Â Â Â Â Â Cookie userCookie = new Cookie("username", username); // Create a cookie that contains the username Cookie passCookie = new Cookie("password", password); // Creates a cookie that contains the password response.addCookie(userCookie); // Send the cookie information to the client response.addCookie(passCookie); return "welcome.jsp"; } } |
Note that the above non compliant 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.
...
The non compliant example above 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.
| Code Block | ||
|---|---|---|
| ||
import java.util.ArrayList; import java.util.List; import javax.servlet.http.*; import edu.cmu.insecure.model.UserDAO; import edu.cmu.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"); String password = request.getParameter("password"); // Basic input validation if(!username.matches("[\\w]*") || !password.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(); session.invalidate(); // Invalidate old session id session = request.getSession(true); // Generate new session id session.setMaxInactiveInterval(2*60*60); // Set session timeout to two hours session.setAttribute("user", dbUser); // Store user bean within the session return "welcome.jsp"; } } |
In the above solution, we have switched from a cookie to a session to store user information. Additionally, the current session is invalidated and a new session is created in order 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 two hours to minimize the window that an attacker has to perform any a session hijacking attack.
...