Summary When using the fiber.Ctx.BodyParser to parse into a struct with range values, a panic occurs when trying to parse a negative range index
Details fiber.Ctx.BodyParser can map flat data to nested slices using key[idx]value syntax, however when idx is negative, it causes a panic instead of returning an error stating it cannot process the data.
Since this data is user-provided, this could lead to denial of service for anyone relying on this fiber.Ctx.BodyParser functionality
Reproducing Take a simple GoFiberV2 server which returns a JSON encoded version of the FormData go package main
import ( "encoding/json" "fmt" "net/http"
"github.com/gofiber/fiber/v2" )
type RequestBody struct { NestedContent []struct { Value string form:"value" } form:"nested-content" }
func main() { app := fiber.New()
app.Post("/", func(c fiber.Ctx) error { formData := RequestBody{} if err := c.BodyParser(&formData); err != nil { fmt.Println(err) return c.SendStatus(http.StatusUnprocessableEntity) } c.Set("Content-Type", "application/json") s, := json.Marshal(formData) return c.SendString(string(s)) })
fmt.Println(app.Listen(":3000")) }
Correct Behaviour Send a valid request such as: bash curl --location 'localhost:3000' \ --form 'nested-content[0].value="Foo"' \ --form 'nested-content[1].value="Bar"' You recieve valid JSON json {"NestedContent":[{"Value":"Foo"},{"Value":"Bar"}]}
Crashing behaviour Send an invalid request such as: bash curl --location 'localhost:3000' \ --form 'nested-content[-1].value="Foo"' The server panics and crashes panic: reflect: slice index out of range
goroutine 8 [running]: reflect.Value.Index({0x738000?, 0xc000010858?, 0x0?}, 0x738000?) /usr/lib/go-1.24/src/reflect/value.go:1418 +0x167 github.com/gofiber/fiber/v2/internal/schema.(Decoder).decode(0xc00002c570, {0x75d420?, 0xc000010858?, 0x7ff424822108?}, {0xc00001c498, 0x17}, {0xc00014e2d0, 0x2, 0x2}, {0xc00002c710, ...}) [...]
Impact Anyone using fiber.Ctx.BodyParser can/will have their servers crashed when an invalid payload is sent
A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to obtain tokens and forge malicious requests on behalf of a user. This can lead to unauthorized actions being taken on the user's behalf, potentially compromising the security and integrity of the application.
Vulnerability Details
The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. The following issues were identified:
1. Lack of Token Association: The CSRF token was validated against tokens in storage but was not tied to the original requestor that generated it, allowing for token reuse.
Remediation
To remediate this vulnerability, it is recommended to take the following actions:
1. Update the Application: Upgrade the application to a fixed version with a patch for the vulnerability.
2. Implement Proper CSRF Protection: Review the updated documentation and ensure your application's CSRF protection mechanisms follow best practices.
4. Choose CSRF Protection Method: Select the appropriate CSRF protection method based on your application's requirements, either the Double Submit Cookie method or the Synchronizer Token Pattern using sessions.
5. Security Testing: Conduct a thorough security assessment, including penetration testing, to identify and address any other security vulnerabilities.
Defence-in-depth
Users should take additional security measures like captchas or Two-Factor Authentication (2FA) and set Session cookies with SameSite=Lax or SameSite=Strict, and the Secure and HttpOnly attributes.
A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to inject arbitrary values and forge malicious requests on behalf of a user. This vulnerability can allow an attacker to inject arbitrary values without any authentication, or perform various malicious actions on behalf of an authenticated user, potentially compromising the security and integrity of the application.
Vulnerability Details
The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. The following issues were identified:
1. Token Injection: For 'safe' methods, the token was extracted from the cookie and saved to storage without further validation or sanitization.
2. Lack of Token Association: The CSRF token was validated against tokens in storage but not associated with a session, nor by using a Double Submit Cookie Method, allowing for token reuse.
Specific Go Packages Affected github.com/gofiber/fiber/v2/middleware/csrf
Remediation
To remediate this vulnerability, it is recommended to take the following actions:
1. Update the Application: Upgrade the application to a fixed version with a patch for the vulnerability.
2. Implement Proper CSRF Protection: Review the updated documentation and ensure your application's CSRF protection mechanisms follow best practices.
4. Choose CSRF Protection Method: Select the appropriate CSRF protection method based on your application's requirements, either the Double Submit Cookie method or the Synchronizer Token Pattern using sessions.
5. Security Testing: Conduct a thorough security assessment, including penetration testing, to identify and address any other security vulnerabilities.
Defence-in-depth
Users should take additional security measures like captchas or Two-Factor Authentication (2FA) and set Session cookies with SameSite=Lax or SameSite=Secure, and the Secure and HttpOnly attributes.
Impact This vulnerability can be categorized as a security misconfiguration. It impacts users of our project who rely on the ctx.IsFromLocal() method to restrict access to localhost requests. If exploited, it could allow unauthorized access to resources intended only for localhost.
In it's implementation it uses c.IPs():
go // IPs returns a string slice of IP addresses specified in the X-Forwarded-For request header. // When IP validation is enabled, only valid IPs are returned. func (c Ctx) IPs() []string { return c.extractIPsFromHeader(HeaderXForwardedFor) }
Thereby, setting X-Forwarded-For: 127.0.0.1 in a request from a foreign host, will result in true for ctx.IsFromLocal()
Patches This issue has been patched in v2.49.2 with commit b8c9ede6efa231116c4bd8bb9d5e03eac1cb76dc
Workarounds Currently, there are no known workarounds to remediate this vulnerability without upgrading to the patched version. We strongly advise users to apply the patch as soon as it is released.
References For further information and context regarding this security issue, please refer to the following resources:
- Mozilla Developer Network - X-Forwarded-For
In Fiber before version 1.12.6, the filename that is given in c.Attachment() (https://docs.gofiber.io/ctx#attachment) is not escaped, and therefore vulnerable for a CRLF injection attack. I.e. an attacker could upload a custom filename and then give the link to the victim. With this filename, the attacker can change the name of the downloaded file, redirect to another site, change the authorization header, etc. A possible workaround is to serialize the input before passing it to ctx.Attachment().