Padding Oracle in Echo Go with Basic Auth

A padding oracle arises when an application exposes different behavior or error messages depending on whether ciphertext padding is valid. In Echo Go, combining Basic Authentication with a custom decryption routine that processes padded payloads can unintentionally create an oracle. If the handler decrypts a token or cookie using a block cipher (e.g., AES-CBC) and then validates credentials, the timing and error paths can leak padding validity before or after checking the username and password.

Consider an endpoint that accepts an encrypted Authorization header value. The server base64-decodes the ciphertext, decrypts it, and then extracts embedded credentials. If the decryption or unpadding code returns distinct errors for invalid padding versus invalid authentication, an attacker can send modified ciphertexts and observe differences in HTTP status codes or response times. This enables iterative decryption and plaintext recovery, even when the endpoint uses Basic Auth for a secondary check. The specific chain — encrypted blob → unpadding → credential parsing → Basic Auth validation — means the oracle is not about the auth mechanism itself, but about how the application signals failure during decryption and padding verification.

For example, if the application uses a naive unpadding implementation that returns an error when padding bytes are incorrect, and this error is surfaced differently than an authentication failure, the attacker can distinguish padding errors from valid-but-wrong credentials. This distinction is amplified when the Basic Auth header is parsed after decryption; the server may leak timing or error information during decryption before rejecting bad credentials. Echo Go handlers that decrypt then call echo.BasicAuth or manually parse Authorization: Basic base64(credentials) after decryption must ensure consistent error handling and constant-time validation to avoid turning the endpoint into a padding oracle.

Remediation focuses on removing timing and error-path distinctions between padding validation and authentication checks. Use a constant-time comparison for credentials and ensure decryption/padding failures result in the same generic error and HTTP status as authentication failures.

Example: Insecure pattern (illustrative only)

// DO NOT USE: illustrates a vulnerable flow
func insecureHandler(c echo.Context) error {
    auth := c.Request().Header.Get("Authorization")
    if auth == "" {
        return echo.NewHTTPError(http.StatusUnauthorized, "missing auth")
    }
    parts := strings.SplitN(auth, " ", 2)
    if len(parts) != 2 || parts[0] != "Basic" {
        return echo.NewHTTPError(http.StatusBadRequest, "invalid auth header")
    }
    decoded, err := base64.StdEncoding.DecodeString(parts[1])
    if err != nil {
        return echo.NewHTTPError(http.StatusBadRequest, "invalid base64")
    }
    creds := string(decoded)
    // Simulate decryption step that may fail with padding errors
    plaintext, err := decrypt(creds)
    if err != nil {
        return echo.NewHTTPError(http.StatusBadRequest, "decryption failed")
    }
    user, pass, ok := strings.Cut(plaintext, ":")
    if !ok || !constantTimeCheck(user, pass) {
        return echo.NewHTTPError(http.StatusUnauthorized, "invalid credentials")
    }
    return c.String(http.StatusOK, "OK")
}

Example: Secure handler in Echo Go

// Secure handler with consistent errors and constant-time checks
func secureHandler(c echo.Context) error {
    auth := c.Request().Header.Get("Authorization")
    if auth == "" {
        return echo.NewHTTPError(http.StatusUnauthorized, "unauthorized")
    }
    parts := strings.SplitN(auth, " ", 2)
    if len(parts) != 2 || parts[0] != "Basic" {
        // Return the same generic error as other failures
        return echo.NewHTTPError(http.StatusUnauthorized, "unauthorized")
    }
    decoded, err := base64.StdEncoding.DecodeString(parts[1])
    if err != nil {
        return echo.NewHTTPError(http.StatusUnauthorized, "unauthorized")
    }
    plaintext, err := decrypt(decoded)
    if err != nil {
        // Treat decryption/padding failures the same as auth failure
        return echo.NewHTTPError(http.StatusUnauthorized, "unauthorized")
    }
    user, pass, ok := strings.Cut(plaintext, ":")
    if !ok || !constantTimeCheck(user, pass) {
        return echo.NewHTTPError(http.StatusUnauthorized, "unauthorized")
    }
    return c.String(http.StatusOK, "authenticated")
}

// constantTimeCheck compares credentials in constant time
func constantTimeCheck(u, p string) bool {
    // Example: compare a stored hash of "user:pass" using subtle.ConstantTimeCompare
    expected := hashUserPass(u, p)
    given := hashUserPass(u, p) // replace with actual input handling
    return subtle.ConstantTimeCompare(expected, given) == 1
}

// decrypt is a stub for your decryption + unpadding logic
// Ensure it returns a generic error on any failure
func解密(data []byte) ([]byte, error) {
    // Implement AES-CBC decryption with proper PKCS7 unpadding
    // If padding is invalid, return a generic error
    return nil, errors.New("decryption error")
}

Key points:

• Return the same generic error message and HTTP status for padding, decryption, and authentication failures.
• Avoid branching on the nature of the decryption error; treat all failures as "unauthorized".
• Use constant-time comparison for credentials after decryption to prevent timing leaks.
• If you use Echo’s built-in Basic Auth helper, ensure your decryption/padding step does not introduce distinguishable behavior before the helper runs.