Distributed Denial Of Service in Fiber

Distributed Denial of Service (DDoS) attacks against Fiber applications exploit the framework's HTTP handling patterns and middleware architecture. In Fiber, DDoS manifests through several specific attack vectors that target the framework's request processing pipeline.

The most common Fiber DDoS attack targets the default middleware stack. When Fiber processes requests through its middleware chain, each layer adds processing overhead. An attacker can exploit this by sending a high volume of requests that trigger expensive middleware operations like authentication, logging, or database queries. Since Fiber processes requests synchronously by default, this can quickly exhaust server resources.

Resource exhaustion in Fiber often occurs in route handlers that perform blocking I/O operations. Fiber's use of net/http under the hood means that each request occupies a goroutine, and with default settings, a server can only handle as many concurrent requests as available goroutines. An attacker can exploit this by sending requests to endpoints that perform slow operations like file uploads, database queries without timeouts, or external API calls.

Another specific Fiber DDoS pattern involves the framework's context handling. Fiber's Context object provides convenient methods for request processing, but attackers can exploit endpoints that read large request bodies without size limits. For example, an endpoint using c.FormFile() without validation can be forced to allocate excessive memory for file uploads, leading to memory exhaustion.

Rate limiting bypasses are particularly effective against Fiber applications that implement naive rate limiting. If rate limiting is implemented at the application level rather than using a distributed cache, an attacker can overwhelm a single instance and cause the entire application to become unresponsive.

Here's a common vulnerable pattern in Fiber applications:

app := fiber.New()

app.Post("/upload", func(c *fiber.Ctx) error {
    // No file size validation
    file, err := c.FormFile("file")
    if err != nil {
        return err
    }
    
    // Process file without limits
    return c.SendString("Upload successful")
})

This endpoint is vulnerable because it accepts any file size without validation, allowing an attacker to upload extremely large files that consume server memory and disk space.

Detecting DDoS vulnerabilities in Fiber applications requires both manual code review and automated scanning. middleBrick's Fiber-specific scanning module identifies DDoS-related issues through several detection mechanisms.

The scanner examines Fiber route handlers for missing input validation and resource limits. It specifically looks for patterns like unvalidated file uploads, unlimited request body sizes, and endpoints that perform expensive operations without rate limiting. middleBrick's black-box scanning tests these endpoints by sending requests with varying payload sizes and observing response times and error rates.

For Fiber applications using middleware, middleBrick analyzes the middleware chain to identify potential bottlenecks. It checks for expensive operations in middleware that execute for every request, such as database connections, external API calls, or complex computations. The scanner also tests for proper error handling, as unhandled errors can cause goroutine leaks that compound under DDoS conditions.

middleBrick's rate limiting detection specifically tests Fiber applications for proper rate limiting implementation. It sends requests at varying rates to identify endpoints that lack rate limiting or have easily bypassable rate limiting mechanisms. The scanner also checks for distributed rate limiting, which is critical for Fiber applications running on multiple instances.

The scanner's input validation testing includes sending malformed requests to Fiber endpoints to check for proper validation and error handling. This helps identify endpoints that might consume excessive resources processing invalid input.

Here's how middleBrick reports DDoS vulnerabilities in Fiber:

{
  "category": "Rate Limiting",
  "severity": "High",
  "finding": "Missing rate limiting on /upload endpoint",
  "remediation": "Implement rate limiting using fiber.RateLimit middleware",
  "impact": "An attacker can exhaust server resources by sending excessive requests",
  "fiber_specific": true
}

The scanner also provides Fiber-specific remediation guidance, such as recommending the use of fiber.RateLimit middleware or suggesting proper context timeout configurations for database operations.

Remediating DDoS vulnerabilities in Fiber applications requires a combination of framework-specific features and Go best practices. The most effective approach is implementing proper rate limiting using Fiber's built-in middleware.

Fiber provides the fiber.RateLimit middleware, which implements token bucket rate limiting. Here's how to properly configure it:

import "github.com/gofiber/fiber/v2"
import "github.com/gofiber/fiber/v2/middleware/rate Limit"

app := fiber.New()

// Configure rate limiting: 100 requests per minute per IP
app.Use(rateLimit.New(rateLimit.Config{
    Timeout: 60000, // 60 seconds
    Limit: 100,
    KeyGenerator: func(c *fiber.Ctx) string {
        return c.IP()
    },
    Filter: func(c *fiber.Ctx) bool {
        // Skip rate limiting for health checks
        return c.Path() != "/health"
    },
    SkipFailedRequests: true,
    SkipSuccessfulRequests: false,
}))

For file upload endpoints, implement strict size validation using Fiber's context methods:

app.Post("/upload", func(c *fiber.Ctx) error {
    // Limit file size to 10MB
    if c.Context().Request().Header.ContentLength() > 10*1024*1024 {
        return c.Status(fiber.StatusRequestEntityTooLarge).SendString("File too large")
    }
    
    // Process file with size validation
    file, err := c.FormFile("file")
    if err != nil {
        return err
    }
    
    // Additional validation
    if file.Size > 10*1024*1024 {
        return c.Status(fiber.StatusRequestEntityTooLarge).SendString("File too large")
    }
    
    return c.SendString("Upload successful")
})

Implement context timeouts for operations that might block:

app.Get("/data", func(c *fiber.Ctx) error {
    // Set 5 second timeout for database operations
    ctx, cancel := context.WithTimeout(c.Context(), 5*time.Second)
    defer cancel()
    
    // Perform database operation with timeout
    result, err := db.Query(ctx, "SELECT * FROM data LIMIT 100")
    if err != nil {
        return c.Status(fiber.StatusGatewayTimeout).SendString("Operation timed out")
    }
    
    return c.JSON(result)
})

For distributed applications, use a distributed rate limiting solution like Redis with Fiber:

import "github.com/go-redis/redis/v8"
import "github.com/gofiber/fiber/v2/middleware/rateLimit"

// Initialize Redis client
var redisClient = redis.NewClient(&redis.Options{
    Addr: "localhost:6379",
})

// Custom rate limiter using Redis
app.Use(func(c *fiber.Ctx) error {
    key := "rate_limit:" + c.IP()
    current, err := redisClient.Get(c.Context(), key).Result()
    if err != nil && err != redis.Nil {
        return err
    }
    
    count, _ := strconv.Atoi(current)
    if count > 100 {
        return c.Status(fiber.StatusTooManyRequests).SendString("Rate limit exceeded")
    }
    
    // Increment counter
    redisClient.Incr(c.Context(), key)
    redisClient.Expire(c.Context(), key, time.Minute)
    
    return c.Next()
})

Implement proper error handling to prevent goroutine leaks:

app.Use(func(c *fiber.Ctx) error {
    // Use defer to recover from panics
    defer func() {
        if r := recover(); r != nil {
            log.Printf("Recovered in middleware: %v", r)
            c.Status(fiber.StatusInternalServerError).SendString("Internal server error")
        }
    }()
    
    return c.Next()
})

These remediation strategies, combined with middleBrick's continuous monitoring, provide comprehensive protection against DDoS attacks targeting Fiber applications.