Skip to main content

Insecurely generated cookies

Need​

Secure generation and handling of cookies

Context​

  • Usage of Java for building scalable and robust applications
  • Usage of javax.servlet.http.Cookie for handling HTTP cookies in Java Servlets
  • Usage of HttpServletRequest for handling HTTP requests in Java Servlets
  • Usage of HttpServletResponse for handling HTTP responses in Java Servlet applications
  • Usage of javax.servlet.ServletException for handling servlet-related exceptions
  • Usage of java.io.IOException for handling input/output exceptions in Java programming

Description​

Non compliant code​

import javax.servlet.http.*;

public class CookieController extends HttpServlet {

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        
        Cookie userCookie = new Cookie("user", "John Doe");
        response.addCookie(userCookie);
    }
}

In the above code, we are creating a new cookie named "user" with the value "John Doe" and adding it to the response. This cookie is then sent to the client's browser where it is stored. The problem here is that the cookie is not set with any security attributes.

When a cookie is not set with security attributes, it is sent over the network in plain text. This means that if an attacker is able to intercept the network traffic (for example, if the user is on an unsecured public Wi-Fi network), they could read the contents of the cookie and gain unauthorized access to sensitive information.

Furthermore, because the cookie is not marked as HttpOnly, it can be accessed by client-side scripts (like JavaScript), which increases the risk of client-side attacks such as Cross-Site Scripting (XSS).

Also, the cookie is not marked as Secure, meaning it can be sent over unencrypted connections, which could be intercepted by attackers.

In summary, the code is vulnerable because it sends sensitive information in a cookie without any security attributes.

Steps​

  • Use secure flag for sensitive cookies
  • Use HttpOnly flag for sensitive cookies
  • Set the cookie path to restrict its scope
  • Set the cookie domain to restrict its scope
  • Use a strong and unique cookie name

Compliant code​

import javax.servlet.http.*;

public class CookieController extends HttpServlet {

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        
        Cookie userCookie = new Cookie("user", "John Doe");
        
        // Set secure flag
        userCookie.setSecure(true);
        
        // Set HttpOnly flag
        userCookie.setHttpOnly(true);
        
        // Set cookie path
        userCookie.setPath("/");
        
        // Set cookie domain
        userCookie.setDomain("yourdomain.com");
        
        response.addCookie(userCookie);
    }
}

The updated code now sets the secure flag for the cookie. This means that the cookie will only be sent over secure (HTTPS) connections. This prevents the cookie from being sent in plain text, which could be intercepted by an attacker.

The HttpOnly flag is also set. This means that the cookie cannot be accessed through client-side scripts. This helps to prevent attacks such as cross-site scripting (XSS) where an attacker might try to access the cookie value through JavaScript.

The path of the cookie is set to the root ("/"). This restricts the scope of the cookie to the entire domain. If you wanted to restrict the cookie to a specific directory, you could change this value.

The domain of the cookie is set to "yourdomain.com". This restricts the scope of the cookie to this specific domain. This means that the cookie will not be sent to any other domains, which could help to prevent attacks where an attacker tries to trick the user's browser into sending the cookie to a different domain.

Finally, the cookie is added to the response. This means that the cookie will be sent to the client's browser along with the HTTP response. The browser will then store the cookie and include it in future requests to the server.

References​

Last updated on