Feature Proposal Description

I see in the Encrypt Cookie middleware there's nothing preventing a malicious user from swapping cookies from one cookie name to another. I've seen other frameworks use various solutions to ensure the cookie is used for it's intended purpose. Laravel for example uses a cookie prefix in it's encryption to ensure it's used for the intended purpose:

laravel/framework/src/Illuminate/Cookie/Middleware/EncryptCookies.php

laravel/framework/src/Illuminate/Cookie/CookieValuePrefix.php

ASP.NET Core uses a purpose string alongside a secret to derive the actual encryption key used for different purposes.

For example for cookie auth the purpose string is made up of the following elements:

"/path/to/app/", "Microsoft.AspNetCore.Authentication.Cookies.CookieAuthenticationMiddleware", "Cookies", "v2"

While this isn't necessarily a big security concern in most applications I see there's a possibility it could be.

I propose that we implement a solution similar to laravel and add a cookie prefix that is the sha1 hmac of the cookie name. This would add 20 bytes to the cookie before encryption if no special encoding is used.

h := hmac.New(sha1.New, keyDecoded)
h.Write([]byte(cookieName))
hash := h.Sum(nil)

//...

ciphertext := gcm.Seal(nonce, nonce, append(hash, []byte(value)...), nil)

And then after decrypting just validate the prefix against the cookie name discarding/clearing the cookie if it's not valid.

If this isn't added could we at least get the cookie name passed into the Encryptor and Decryptor functions so that custom implementations could use the cookie name for validation?

There are also a few other solutions for additional cookie validation. One of which is to use a custom middleware that runs after decryption that checks a cookie prefix against the cookie name and also adds the cookie prefix before the encryption step.

Alignment with Express API

N/A

HTTP RFC Standards Compliance

I think section 8 of RFC6265 might be relevant in that cookies provide weak integrity:
RFC6265 Section 8

API Stability

This in itself would be an unstable change in that all previously issued cookies would become invalid. As a workaround this feature could be opt in instead of default behavior.

Feature Examples

N/A

Checklist:

• I agree to follow Fiber's Code of Conduct.
• I have searched for existing issues that describe my proposal before opening this one.
• I understand that a proposal that does not meet these guidelines may be closed without explanation.