Cross Site Request Forgery (CSRF)
ID |
go.cross_site_request_forgery |
Severity |
high |
Resource |
Authentication |
Language |
Go |
Tags |
CWE:352, NIST.SP.800-53, OWASP:2013:A8, PCI-DSS:6.5.1 |
Description
Cross-Site Request Forgery (CSRF) is a security vulnerability that occurs when a malicious actor tricks a user’s browser into performing unwanted actions on a trusted web application where the user is authenticated. It primarily exploits the trust that a web application has in an authenticated user’s browser.
It can lead to unauthorized actions being executed in a web application on behalf of the user, potentially compromising personal data, making unauthorized transactions, or performing administrative operations.
Rationale
CSRF exploits the trust that a web application has in the user’s browser. Essentially, the attacker crafts a request that the user’s browser sends to a web server where the user is authenticated.
The key vulnerability is the application’s inability to verify that the request originated from its own legitimate web pages and intentionally made by the user, rather than from a malicious site. This is why CSRF protections typically involve adding unique tokens to forms that the server can verify came from its own pages.
If the vulnerable application does not have the necessary protection, the attacker can execute arbitrary actions on the user’s behalf.
In Golang web frameworks (such as Echo or Fiber), forms and state-changing requests are vulnerable to CSRF unless adequately protected. For example, a form submission without a CSRF token can be exploited:
package main
import (
"github.com/gofiber/fiber/v2"
)
func main() {
app := fiber.New() // FLAW
app.Post("/", func(c *fiber.Ctx) error {
url := c.FormValue("url")
c.Location(url)
// Optionally set a status code
return c.SendStatus(fiber.StatusFound)
})
// Start server
app.Listen(":3000")
}
Remediation
The most common protection strategy against CSRF is to use anti-CSRF tokens, to ensure that requests are originated from the legitimate user. The token should be generated on the server backend, and included in every form or request to the backend.
Additional protection techniques that do not seclude the need for anti-CSRF token:
-
Validate Referer Header: In some cases, checking the
Referer
orOrigin
headers can provide another layer of protection, ensuring that the request originates from the same site. -
Force User Interaction: Force significant actions to require additional confirmation steps, like re-authentication or other forms of verification.
-
SameSite Cookie Attribute: Use the
SameSite
attribute for cookies to prevent them from being sent in cross-site requests.
Implementing these strategies in your applications will significantly reduce the risk of CSRF attacks.
To safeguard Golang web applications against CSRF, they should employ CSRF tokens in forms that perform state-changing actions.
Beego
web.BConfig.WebConfig.EnableXSRF
Beego configuration helps to automate this process by managing CSRF token creation and verification.
Buffalo
github.com/gobuffalo/buffalo/middleware/csrf
Buffalo middleware helps to automate this process by managing CSRF token creation and verification.
Echo
github.com/labstack/echo/middleware/CSRF
middleware helps to automate this process by managing CSRF token creation and verification.
Fiber
github.com/gofiber/fiber/v2/middleware/csrf
middleware helps to automate this process by managing CSRF token creation and verification.
Gin Gonic
github.com/tommy351/gin-csrf
middleware helps to automate this process by managing CSRF token creation and verification.
Iris
github.com/iris-contrib/middleware/csrf
middleware helps to automate this process by managing CSRF token creation and verification.
Martini
github.com/martini-contrib/csrf
middleware helps to automate this process by managing CSRF token creation and verification
References
-
CWE-352 : Cross-Site Request Forgery (CSRF)
-
OWASP - Top 10 2021 Category A01 : Broken Access Control.
-
Cross-Site Request Forgery Prevention Cheat Sheet, in OWASP Cheat Sheet Series.