...
In this noncompliant code example, 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 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 noncompliant code example stores the user name and password within two cookie objects, which are sent to the client to be stored in a cookie. This code example is insecure because an attacker can discover this information by performing a cross-site scripting an XSS attack or by sniffing packets. Once the attacker gains access to the user name and password, he or she can freely log in to the user's account. Even if the application had stored only the user name within the cookie for authentication purposes, an attacker could still use the user name to forge his or her own cookie and bypass the authentication system.
...
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 cross-site scripting XSS or man-in-the-middle attacks to gain direct access to the session information. Rather, the cookie stores a session id 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 idID.
| Code Block | ||
|---|---|---|
| ||
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";
}
}
|
...
Violation of this rule places sensitive information within cookies, making the information vulnerable to packet sniffing or cross-site scripting XSS attacks.
Related Guidelines
Bibliography
...