When building an application that uses a client-server model, storing sensitive information, such as user credentials, on the client side may result in its unauthorized disclosure if the client is vulnerable to attack.
For web applications, the most common mitigation to this problem is to provide the client with a cookie and store the sensitive information on the server. Cookies are created by a web server and are stored for a 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. When the client reconnects to the server, it provides the cookie, which identifies the client to the server, and the server then provides the sensitive information.
Cookies do not protect sensitive information against '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 attacks. An attacker who is able to obtain a cookie either through an XSS attack or directly by attacking the client can obtain the sensitive information from the server using the cookie. This risk is timeboxed if the server invalidates the session after a limited time has elapsed, such as 15 minutes.
A cookie is typically a short string. If it contains sensitive information, that information should be encrypted. Sensitive information includes passwords, credit card numbers, social security numbers, and any other 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. For more details about managing passwords, see MSC62-J. Store passwords using a hash function. For more information about securing the memory that holds sensitive information, see MSC59-J. Limit the lifetime of sensitive data.
Noncompliant Code Example
In this non compliant noncompliant code example, we can see that the login servlet stores the user name and password in the cookie to identify the user for authentication purposes.subsequent requests:
| 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>protected void doPost(HttpServletRequest request, HttpServletResponse response) { // Validate input (omitted) String username = request.getParameter("username"); char[] password = request.getParameter("password").toCharArray(); boolean rememberMe = Boolean.valueOf(request.getParameter("rememberme")); LoginService loginService = new LoginServiceImpl(); if (rememberMe) { if (request.setAttribute("errors", errors); Â Â Â Â Â Â Â getCookies()[0] != null && String username = request.getParameter("username"); getCookies()[0].getValue() != null) { String[] passwordvalue = request.getParameter.getCookies()[0].getValue().split("password;"); Â Â Â Â Â Â // Basic input validation if if(!usernameloginService.matchesisUserValid("value[\\w]*") || !password.matches("[\\w]*"0], value[1].toCharArray())) { errors.add("Incorrect user name or password format."); // Set error and return } else { return "error.jsp"; // Forward to welcome page } Â Â Â Â Â } else { UserBean dbUser boolean validated = thisloginService.userDAO.lookupisUserValid(username, password); if(!dbUser.checkPassword(password)) (validated) { errors.add("Passwords do not match.") Cookie loginCookie = new Cookie("rememberme", username + ";" + new String(password)); return "error.jsp" response.addCookie(loginCookie); } Â Â Â Â Â Â // ... Forward to welcome page } else { Cookie userCookie = new Cookie("username", username); // Create a cookie that contains the username Set error and return } Cookie passCookie = new Cookie("password", password); // Creates a cookie that contains the password} } else { // No remember-me functionality selected // Proceed with regular authentication; response.addCookie(userCookie); // Sendif theit cookiefails informationset toerror theand clientreturn response.addCookie(passCookie); } return "welcome.jsp"; }Arrays.fill(password, ' '); } |
Note that the above non compliant code example stores the user name and password within the cookie for authentication purposes. This particular code example However, the attempt to implement the remember-me functionality 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
with access to the client machine can obtain this information directly on the client. This code also violates MSC62-J. Store passwords using a hash function. The client may also have transmitted the password in clear unless it encrypted the password or uses HTTPS.
Compliant Solution (Session)
This compliant solution implements the remember-me functionality by storing the user name and a secure random string in the cookie. It also maintains state in the session using HttpSessionThe 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 | ||
|---|---|---|
| ||
public class InsecureServlet extends HttpServletprotected void doPost(HttpServletRequest request, HttpServletResponse response) { private UserDAO userDAO; // Validate input (omitted) String //username = request.getParameter("username"); char[] password = request.getParameter("password").toCharArray(); boolean rememberMe = Boolean.valueOf(request.getParameter("rememberme")); LoginService privateloginService = Stringnew login(HttpServletRequest request, HttpServletResponse responseLoginServiceImpl(); boolean validated = false; if (rememberMe) { List<String> errors = new ArrayList<String>();if (request.getCookies()[0] != null && request.setAttribute("errors", errors); getCookies()[0].getValue() != null) { String[] usernamevalue = request.getParametergetCookies()[0].getValue().split("username;"); String password = request.getParameter("password"); if (value.length != 2) { // Basic input validation Set error and return } if (!usernameloginService.matchesmappingExists("value[\\w]*") || !password.matches("[\\w]*"0], value[1])) { errors.add("Incorrect user name or password format."); // (username, random) pair is checked // returnSet "error.jsp"; error and return } } else { UserBean dbUservalidated = thisloginService.userDAO.lookupisUserValid(username, password); if if (!dbUser.checkPassword(passwordvalidated)) { // Set error and return errors.add("Passwords do not match."} } String newRandom = loginService.getRandomString(); // Reset the random return "error.jsp";every time } loginService.mapUserForRememberMe(username, newRandom); HttpSession session = request.getSession(); session.invalidate(); // Invalidate old session id session = request.getSession(true); // Set Generatesession timeout newto session15 idminutes session.setMaxInactiveInterval(2*60 *60 15); // Set session timeout to two hoursStore user attribute and a random attribute in session scope session.setAttribute("user", dbUserloginService.getUsername()); // Store user bean within the session Cookie loginCookie = new Cookie("rememberme", username + ";" + newRandom); loginCookie.setHttpOnly(true); return "welcome.jsp";loginCookie.setSecure(true); response.addCookie(loginCookie); // ... Forward to welcome page } else { // No remember-me functionality selected // ... Authenticate using isUserValid() and if failed, set error } |
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.
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
Arrays.fill(password, ' ');
}
|
The server maintains a mapping between user names and secure random strings. When a user selects “Remember me,” the doPost() method checks whether the supplied cookie contains a valid user name and random string pair. If the mapping contains a matching pair, the server authenticates the user and forwards him or her to the welcome page. If not, the server returns an error to the client. If the user selects “Remember me” but the client fails to supply a valid cookie, the server requires the user to authenticate using his or her credentials. If the authentication is successful, the server issues a new cookie with remember-me characteristics.
This solution avoids session-fixation attacks by invalidating the current session and creating a new session. It also reduces the window during which an attacker could perform a session-hijacking attack by setting the session timeout to 15 minutes between client accesses.
Applicability
Storing unencrypted sensitive information on the client makes this information available to anyone who can attack the client.
Bibliography
...
Wiki Markup