Storing sensitive information at client-side may result in its disclosure if an application is vulnerable to attacks that can compromise the information. For example, consider the use of a cookie for storing sensitive information such as user credentials. A cookie is set by a web server and is stored for a certain period of time on the client-side. All subsequent requests to the domain identified by the cookie are made to contain information that was saved in the cookie. If the web application is vulnerable to a cross-site scripting (XSS) vulnerability, an attacker may be able to read any unencrypted information contained in the cookie.
A partial list of sensitive information includes user names, passwords, password hashes, credit card numbers, social security numbers, and any other personally identifiable information about the user.
Noncompliant Code Example
In this noncompliant code example, the servlet stores the user name and password in the cookie to identify the user for subsequent requests:
protected void doPost(HttpServletRequest request, HttpServletResponse response) {
String username = request.getParameter("username");
char[] password = request.getParameter("password").toCharArray();
LoginService loginService = new LoginServiceImpl();
boolean validated = loginService.isUserValid(username, password);
if (validated) {
Cookie loginCookie = new Cookie("credentials", username + ";"
+ password.toString());
response.addCookie(loginCookie);
// ... forward to welcome page
} else {
// ... set error
}
Arrays.fill(password, ' ');
}
However, the attempt to implement the "remember me" functionality is insecure because sensitive information should not be stored at client-side without strong encryption.
Compliant Solution (Session)
- TODO - I need to re-do this Dhruv Mohindra
This compliant solution stores user information using the HttpSesssion class within the javax.servlet.http package. Because HttpSession objects are server-side, an attacker cannot use XSS or man-in-the-middle attacks to gain direct access to the session information. Rather, the cookie stores a session ID that refers to the user's HttpSession object stored on the server. Consequently, the attacker cannot gain access to the user's account details without first gaining access to the session ID.
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 avoids session fixation attacks [OWASP 2009] by invalidating the current session and creating a new session. It also reduces the window in which an attacker could perform a session hijacking attack by setting the session timeout to one.
Applicability
Violation of this rule places sensitive information within cookies, making the information vulnerable to packet sniffing or XSS attacks.
Related Guidelines
Bibliography