Skip to main content

Insecurely generated cookies - SameSite

Need​

Secure generation of cookies with proper SameSite attribute

Context​

  • Usage of Go 1.16 for building high-performance and concurrent applications
  • Usage of gin-gonic/gin for building web applications in Go
  • Usage of net/http for handling HTTP requests and building web servers

Description​

Non compliant code​

package main

import (
	"github.com/gin-gonic/gin"
	"net/http"
)

func main() {
	r := gin.Default()

	r.GET("/", func(c *gin.Context) {
		cookie := &http.Cookie{
			Name:     "session_id",
			Value:    "123",
			Path:     "/",
			HttpOnly: true,
		}
		http.SetCookie(c.Writer, cookie)
		c.String(http.StatusOK, "Cookie set")
	})

	r.Run()
}

The above code is a simple Go server using the Gin framework. It has an endpoint at the root ("/") that, when accessed, sets a cookie named "session_id" with a value of "123".

The vulnerability lies in the way the cookie is set. The http.SetCookie function sets a cookie without the SameSite attribute. The SameSite attribute is a reasonably new security feature that allows a server to declare if their cookies should be restricted to a first-party or same-site context. In other words, it determines if the cookie should be sent with cross-site requests.

Without the SameSite attribute, the cookie "session_id" could be sent along with the request even when the request originated from a different site. This opens up the possibility for Cross-Site Request Forgery (CSRF) attacks, where an attacker tricks a victim into performing actions on their behalf.

In a CSRF attack, the attacker's site could send a request to the server that looks like it's from a logged-in user. Since the server can't tell the difference (because the cookie doesn't have the SameSite attribute), it would perform the action as if the user had initiated it. This could lead to unauthorized actions being performed without the user's knowledge.

Steps​

  • Set the SameSite attribute of the cookie to 'Strict' or 'Lax' to prevent cross-site request forgery (CSRF) attacks.
  • Use the Secure attribute to ensure that the cookie is only sent over HTTPS connections.
  • Set the MaxAge attribute to specify the maximum age of the cookie.
  • Use a cryptographically secure random number generator to generate the cookie value.
  • Implement a session management system to handle session-related operations securely.

Compliant code​

package main

import (
	"github.com/gin-gonic/gin"
	"net/http"
	"time"
)

func main() {
	r := gin.Default()

	r.GET("/", func(c *gin.Context) {
		cookie := &http.Cookie{
			Name:     "session_id",
			Value:    "123", // This should be replaced with a securely generated value
			Path:     "/",
			HttpOnly: true,
			Secure:   true,
			SameSite: http.SameSiteStrictMode,
			MaxAge:   3600, // This is 1 hour
		}
		http.SetCookie(c.Writer, cookie)
		c.String(http.StatusOK, "Cookie set")
	})

	r.Run()
}

The updated code now sets the SameSite attribute of the cookie to http.SameSiteStrictMode. This means that the cookie will only be sent in a first-party context and not be sent along with requests initiated by third party websites. This helps to mitigate CSRF attacks.

The Secure attribute is also set to true, which means that the cookie will only be sent over HTTPS connections. This helps to prevent man-in-the-middle attacks where an attacker might intercept the cookie as it is sent over an insecure connection.

The MaxAge attribute is set to 3600 seconds, which is equivalent to 1 hour. This means that the cookie will expire after 1 hour. This helps to limit the duration of potential attacks as an attacker would need to use the cookie before it expires.

The Value attribute is still set to a static value of "123". This should be replaced with a value generated using a cryptographically secure random number generator. This helps to prevent attacks where an attacker might guess or brute-force the cookie value.

Finally, it's recommended to implement a session management system to handle session-related operations securely. This could include operations such as generating new session IDs, invalidating sessions, and handling session timeouts.

References​

Last updated on