Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: substantial grammar fixes, moderate re-writing.

Cookies are an essential part of any web application and can be ; they are used for a number of different purposes such as many purposes, including 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 is sent in all subsequent requests to the cookie domain. Because of thisConsequently, the information within a cookie is not secure and can be retrieved through a variety of attacks such as insecure; it is vulnerable to 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 (among others). Servers must ensure that cookies lack excess or sensitive information about a user. This includes, but is not limited to, users. A partial list of such information includes user names, passwords, password hashes, credit cards, and any personally identifiable information about the user.

...

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.

Code Block
bgColor#FFcccc
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 two cookie objects, which will be are sent to the client to be stored in a cookie. This particular code example is insecure because an attacker could possibly perform can discover this information by performing a cross-site scripting attack or sniff packets to find this informationby sniffing packets. Once the attacker finds this information, they have free reign to gains access to the username and password, he can freely log in to the user's account. On the other hand, Even if the application had stored only stored the user name within the cookie for authentication purposes, an attacker could still use the user name to forge their his own cookie and consequently bypass the authentication system.

Compliant Solution

The previous noncompliant example can be resolved by This compliant solution stores user information using the HttpSesssion class within the javax.servlet.http package ?to store user information as opposed to cookies. Since . Because HttpSession objects are server-side, it is impossible for an attacker to gain access to the session information directly through cannot use cross-site scripting or man-in-the-middle attacks . Instead, to directly gain access to the session information. Rather, the cookie stores a session id is stored within the cookie to refer to that refers to the user's HttpSession object stored on the server. As a resultConsequently, the attacker must first cannot gain access to the session id and only then do they have a chance of gaining access to a user's account details without first gaining access to the session id.

Code Block
bgColor#ccccff
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";
  }
}

Wiki Markup
This solution usesalso a session and not a cookie to store user information. Additionally, invalidates the current session isand invalidated andcreates a new session is created to avoid session fixation attacks; as noted by The Open Web Application Security Project see \[SD:OWASP 2009\] .  The timeout of the session has also been set to one hour to minimize solution also reduces the window thatin which an attacker has tocould perform any a session hijacking attack by setting the session timeout to one.

Risk Assessment

Noncompliance may lead to Violation of this guideline places sensitive information being stored within a cookie, which may be accessible via cookies, making the information vulnerable to packet sniffing or cross-site scripting attacks.

...