Crlf Injection in Fiber

Crlf injection attacks exploit the way HTTP headers are parsed by inserting carriage return and line feed characters (%0D%0A) into user-controlled input. In Fiber applications, this vulnerability often appears when user input is incorporated into HTTP headers without proper sanitization.

The most common Fiber-specific manifestation occurs when constructing Set-Cookie headers. Consider this vulnerable pattern:

func loginHandler(c *fiber.Ctx) error {
    username := c.FormValue("username")
    
    // VULNERABLE: Direct header injection possible
    c.Set("Set-Cookie", fmt.Sprintf("session=%s; HttpOnly", username))
    
    return c.JSON(fiber.Map{"status": "logged in"})
}

If an attacker submits admin%0D%0AContent-Type%3A%20text/html%0D%0A%0D%0A%3Cscript%3Ealert(1)%3C/script%3E as the username, the response headers become:

Set-Cookie: session=admin
Content-Type: text/html

<script>alert(1)</script>

This creates a response-splitting scenario where the attacker injects arbitrary headers and body content.

Another Fiber-specific vector is when using c.Redirect() with user-controlled URLs:

func redirectHandler(c *fiber.Ctx) error {
    target := c.Query("url")
    
    // VULNERABLE: CRLF injection in Location header
    return c.Redirect(target)
}

An attacker could redirect to http://evil.com%0D%0ASet-Cookie%3A%20evil=true, injecting headers into the redirect response.

Header manipulation through c.Append() and c.JSON() also presents risks when user input appears in header values:

func profileHandler(c *fiber.Ctx) error {
    bio := c.FormValue("bio")
    
    // VULNERABLE: CRLF in custom header
    c.Append("X-User-Bio", bio)
    return c.JSON(fiber.Map{"bio": bio})
}

The Fiber framework itself doesn't automatically sanitize header values, making it the developer's responsibility to validate input before including it in HTTP headers.

Detecting CRLF injection in Fiber applications requires both static code analysis and runtime scanning. middleBrick's black-box scanner can identify these vulnerabilities without access to source code by sending specially crafted payloads and analyzing responses.

middleBrick tests for CRLF injection by sending requests with encoded %0D%0A sequences in various header positions and checking if the response structure changes unexpectedly. For Fiber applications, it specifically targets:

• Cookie manipulation attempts in authentication endpoints
• Redirect functionality with user-controlled URLs
• Custom header generation from user input
• JSON responses where header injection could alter content-type or other security headers

The scanner examines response headers for anomalies like unexpected Set-Cookie headers, duplicate headers, or content-type changes that weren't present in baseline requests.

For proactive detection in your Fiber codebase, use this pattern to identify vulnerable code:

# Search for header-related vulnerabilities
grep -r "c\.Set(" . --include="*.go"
grep -r "c\.Redirect(" . --include="*.go"
grep -r "fmt\.Sprintf.*%" . --include="*.go" | grep -E "(Set|Redirect|Header)"

middleBrick's continuous monitoring (Pro plan) can automatically scan your staging APIs on a schedule, alerting you when new endpoints introduce CRLF vulnerabilities. The scanner provides specific findings with severity levels and remediation guidance mapped to OWASP API Security Top 10 risks.

Integration with GitHub Actions allows you to fail CI builds when CRLF injection risks are detected:

- name: Scan for CRLF Injection
  uses: middleBrick/middlebrick-action@v1
  with:
    api_url: ${{ secrets.TEST_API_URL }}
    fail_threshold: "B"

This ensures CRLF injection vulnerabilities are caught before deployment to production environments.

Remediating CRLF injection in Fiber requires input validation and sanitization before using user data in HTTP headers. The most effective approach is to use Fiber's built-in utilities combined with strict validation.

For cookie handling, validate and sanitize input before setting headers:

import (
    "regexp"
    "github.com/gofiber/fiber/v2"
)

var crlfPattern = regexp.MustCompile(`[\r\n]`)

func safeSetCookie(c *fiber.Ctx, name, value string) {
    sanitizedValue := crlfPattern.ReplaceAllString(value, "_")
    c.Set("Set-Cookie", fmt.Sprintf("%s=%s; HttpOnly; Secure", name, sanitizedValue))
}

For redirect handling, validate URLs against a whitelist or use Fiber's safe redirect methods:

func safeRedirect(c *fiber.Ctx, url string) error {
    // Basic URL validation
    if !strings.HasPrefix(url, "https://yourdomain.com/") {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "Invalid redirect URL"})
    }
    
    // Sanitize for CRLF
    sanitizedURL := crlfPattern.ReplaceAllString(url, "")
    return c.Redirect(sanitizedURL)
}

When using c.JSON() with user-controlled data that might appear in headers, validate all input fields:

type UserProfile struct {
    Bio string `json:"bio"`
}

func validateProfileInput(input UserProfile) error {
    if crlfPattern.MatchString(input.Bio) {
        return errors.New("bio contains invalid characters")
    }
    return nil
}

For comprehensive protection, implement a middleware that sanitizes all header values:

func crlfProtectionMiddleware() fiber.Handler {
    return func(c *fiber.Ctx) error {
        // Sanitize incoming query parameters and form values
        c.QueryParser(func(value string) string {
            return crlfPattern.ReplaceAllString(value, "_")
        })
        
        // Continue to next middleware/handler
        return c.Next()
    }
}

Register this middleware globally:

app := fiber.New()
app.Use(crlfProtectionMiddleware())

middleBrick's scanning can verify these remediations by testing the same attack vectors and confirming that injected CRLF sequences are properly neutralized. The scanner provides specific feedback on whether your validation logic effectively prevents header injection attacks.