Cookies are an essential part of any web application; they are used for many purposes, including user authentication. A cookie is a small piece of data that 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 's response and is stored for a certain period of time on the client's computer. After a cookie is set, all -side. All subsequent requests to the cookie domain include all of the information held by identified by the cookie are made to contain information that was saved in the cookie. Consequently, the information within a cookie is insecure; it If the web application is vulnerable to a cross-site scripting vulnerability, an attacker may be able to read any unencrypted information contained in the cookie.
(XSS) and man-in-the-middle attacks (among others). Servers must ensure that cookies lack excess or sensitive information about users. A partial list of such sensitive information includes user names, passwords, password hashes, credit cardscard 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 authentication purposessubsequent 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 loginprotected void doPost(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(); LoginService loginService //= 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(usernamenew LoginServiceImpl(); boolean validated = loginService.isUserValid(username, password); if (!dbUser.checkPassword(password))validated) { Cookie loginCookie = new errors.addCookie("credentials"Passwords, dousername 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 + password.toString()); Cookie passCookie = new Cookie("password", passwordresponse.addCookie(loginCookie); // Add... theforward cookie information to the response that the client will receivewelcome page } response.addCookie(userCookie);else { response.addCookie(passCookie); // Clear... passwordset char arrayerror } 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 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.
...
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.
...
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
...