Crlf Injection in Echo Go (Go)

Crlf Injection occurs when an attacker can inject a CRLF sequence (\r\n) into a header or the response body, causing the header to be split and potentially injecting additional headers or body content. In Echo Go, this can arise when user-controlled data is reflected into HTTP response headers without validation or sanitization. For example, if a handler sets a custom header using values from query parameters or cookies, an attacker can supply \r\n to terminate the intended header and append new headers such as Set-Cookie or X-Content-Type-Options.

Echo Go applications that stream responses or use custom middleware that manipulates headers are particularly at risk. Because Echo Go does not inherently sanitize header values, the framework expects developers to validate and encode any data placed into headers. An attacker might supply a payload like X-Test: foo\r\nSet-Cookie: token=stolen. If Echo Go writes this header value directly, the CRLF splits the header, and the injected header is interpreted by the client, enabling session fixation, HTTP response splitting, or cross-site scripting in clients that render injected content.

Real-world impact includes response splitting, cache poisoning, and client-side injection. While Echo Go is a server-side framework, the injected CRLF affects clients and intermediaries that process the raw HTTP stream. In unauthenticated scans, middleBrick tests for CRLF injection by submitting header-like payloads and observing whether the response contains duplicated or split headers. The presence of unexpected headers in the output indicates that user input has not been sanitized before being reflected into the protocol stream.

Moreover, CRLF Injection can compound other issues such as Data Exposure when injected headers cause sensitive information to be revealed, or when injected content changes the effective request path. Because Echo Go relies on developer discipline to keep headers clean, misconfigurations or oversight in input validation can expose the application to protocol-level attacks that are detectable through black-box scanning techniques like those run by middleBrick.

To remediate Crlf Injection in Echo Go, ensure that any user-controlled data placed into HTTP headers is stripped of CRLF characters before being used. The simplest and most effective approach is to sanitize inputs by removing carriage return (\r) and line feed (\n) characters, or by rejecting inputs that contain these characters when they are not expected.

Below is a secure Echo Go handler that sanitizes a user-supplied header value. It uses Go’s strings mapping to remove any \r or \n characters, ensuring that no CRLF injection can occur.

package main

import (
    "net/http"
    "strings"

    "github.com/labstack/echo/v4"
)

// sanitizeHeader removes CR and LF characters to prevent CRLF injection.
func sanitizeHeader(value string) string {
    return strings.ReplaceAll(strings.ReplaceAll(value, "\r", ""), "\n", "")
}

func main() {
    e := echo.New()

    e.GET("/set-header", func(c echo.Context) error {
        userValue := c.QueryParam("name")
        safeValue := sanitizeHeader(userValue)
        c.Response().Header().Set("X-Custom-Name", safeValue)
        return c.String(http.StatusOK, "OK")
    })

    e.Logger.Fatal(e.Start(":8080"))
}

For cases where headers should not contain newlines at all, it is safer to reject the request rather than modify the input. The following example returns a 400 Bad Request if the header value contains any newline or carriage return characters.

package main

import (
    "net/http"
    "strings"

    "github.com/labstack/echo/v4"
)

func containsCRLF(value string) bool {
    return strings.ContainsAny(value, "\r\n")
}

func main() {
    e := echo.New()

    e.GET("/strict-header", func(c echo.Context) error {
        userValue := c.QueryParam("token")
        if containsCRLF(userValue) {
            return c.String(http.StatusBadRequest, "invalid header value")
        }
        c.Response().Header().Set("Authorization-Token", userValue)
        return c.String(http.StatusOK, "accepted")
    })

    e.Logger.Fatal(e.Start(":8080"))
}

When using Echo’s middleware to set headers globally, apply the same sanitization across the middleware chain to prevent accidental leakage. Additionally, avoid concatenating user input directly into header values; prefer structured data and encoding techniques that do not require raw header injection. These practices align with secure handling of HTTP headers in Go and reduce the risk of CRLF Injection across the application surface.