logo

Insecurely generated cookies - SameSite - Go


Need

Secure generation of cookies with proper SameSite attribute


Context

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

Description

Insecure Code Example

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

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

Secure Code Example

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

  • 129 - Insecurely generated cookies - SameSite

  • Last updated

    2023/09/18