Padding Oracle in Chi with Api Keys

A padding oracle attack in the context of API authentication using API keys occurs when an endpoint reveals whether a provided key is correctly padded before completing the decryption or verification step. In Chi, this typically arises when a request contains an encrypted or signed token (e.g., a JWT or API key blob) and the server responds with distinct timing differences or specific error messages depending on whether the padding is valid. An attacker can exploit these behavioral differences iteratively to decrypt or forge authenticated requests without knowing the secret key.

Chi is a functional, composable router for the Go programming language often used to build HTTP services. When API keys are handled by decrypting an encrypted cookie or header using block ciphers (e.g., AES-CBC) without proper constant-time comparison or authenticated encryption, a padding oracle may be inadvertently exposed. For example, if a Chi middleware decrypts an encrypted API key payload and then validates padding using standard library functions that return errors distinguishable to the attacker, each crafted request can provide a byte of information. Over many requests, this allows an attacker to recover the plaintext key or to construct valid encrypted keys for unauthorized access.

Consider a scenario where an API key is stored encrypted in a cookie and the server uses a custom decryption routine in a Chi route. If the server returns a 400 Bad Request for invalid padding and a 401 Unauthorized for valid padding but invalid signature, an attacker can perform a padding oracle attack by observing HTTP status codes and response times. Real-world attacks such as those described in CVE-2016-2183 (affecting TLS implementations using CBC mode with predictable IVs) illustrate the impact of padding oracles when confidentiality and integrity protections are weak. In Chi services, similar risks emerge when cryptographic operations are not implemented with authenticated encryption or constant-time checks.

To illustrate, the following Chi middleware demonstrates an insecure pattern that can lead to padding oracle behavior. Note the use of a custom decryption function that returns distinct errors for padding failures versus signature mismatches, which an attacker can differentiate:

package main

import (
	"crypto/aes"
	"crypto/cipher"
	"errors"
	"net/http"

	"github.com/go-chi/chi/v5"
)

// Insecure decryption helper that may leak padding validity via errors.
func decryptKey(data, key []byte) ([]byte, error) {
	block, err := aes.NewCipher(key)
	if err != nil {
		return nil, err
	}
	// Assume PKCS7 padding and CBC mode for illustration.
	if len(data)%aes.BlockSize != 0 {
		return nil, errors.New("invalid block size")
	}
	mode := cipher.NewCBCDecrypter(block, data[:aes.BlockSize])
	plaintext := make([]byte, len(data)-aes.BlockSize)
	mode.CryptBlocks(plaintext, data[aes.BlockSize:])
	// Simulate padding validation that returns distinct errors.
	if err := validatePKCS7(plaintext); err != nil {
		return nil, errors.New("invalid padding")
	}
	return plaintext, nil
}

func validatePKCS7(data []byte) error {
	// Simplified validation that could leak timing or error type.
	paddingLen := int(data[len(data)-1])
	if paddingLen <= 0 || paddingLen > aes.BlockSize {
		return errors.New("invalid padding length")
	}
	for i := len(data) - paddingLen; i < len(data); i++ {
		if data[i] != byte(paddingLen) {
			return errors.New("invalid padding bytes")
		}
	}
	return nil
}

func insecureHandler(w http.ResponseWriter, r *http.Request) {
	apiKeyEncrypted := r.Header.Get("X-Encrypted-Key")
	// In real code, decode base64 and handle errors properly.
	decrypted, err := decryptKey([]byte(apiKeyEncrypted), []byte("32-byte-long-key-32-byte-long-key"))
	if err != nil {
		http.Error(w, err.Error(), http.StatusBadRequest)
		return
	}
	w.Write(decrypted)
}

func main() {
	r := chi.NewRouter()
	r.HandleFunc("/resource", insecureHandler)
	http.ListenAndServe(":8080", r)
}

In this example, an attacker can send modified ciphertexts and observe whether the server responds with "invalid padding" versus "invalid padding" combined with other status codes or timing differences. By systematically adapting ciphertext blocks, the attacker can eventually recover the plaintext API key. Remediation involves using authenticated encryption with associated data (AEAD) such as AES-GCM and ensuring constant-time validation, which middleBrick scans can help detect by identifying inconsistent error handling and missing integrity checks in Chi-based API configurations.

Remediation focuses on replacing custom decryption and padding validation with standard, well-audited cryptographic primitives. Use authenticated encryption (e.g., AES-GCM) so that decryption either succeeds and returns valid plaintext or fails with a single generic error, eliminating padding oracle behavior. Additionally, perform constant-time comparisons for any key material and avoid branching on secret-dependent data. The following Chi middleware demonstrates a secure approach using Go's standard library.

First, prefer AES-GCM for encrypting and authenticating API keys. This ensures integrity and confidentiality in a single step, making padding oracles impossible because decryption either verifies the authentication tag fully or returns an error without revealing details:

package main

import (
	"crypto/aes"
	"crypto/cipher"
	"crypto/rand"
	"encoding/base64"
	"errors"
	"io"
	"net/http"

	"github.com/go-chi/chi/v5"
)

// SecureEncryptAEAD encrypts plaintext with AES-GCM and returns base64 ciphertext.
func secureEncryptAEAD(plaintext, key []byte) (string, error) {
	block, err := aes.NewCipher(key)
	if err != nil {
		return "", err
	}
	gcm, err := cipher.NewGCM(block)
	if err != nil {
		return "", err
	}
	nonce := make([]byte, gcm.NonceSize())
	if _, err := io.ReadFull(rand.Reader, nonce); err != nil {
		return "", err
	}
	ciphertext := gcm.Seal(nonce, nonce, plaintext, nil)
	return base64.StdEncoding.EncodeToString(ciphertext), nil
}

// SecureDecryptAEAD decrypts base64 ciphertext and verifies authentication.
func secureDecryptAEAD(ciphertextB64 string, key []byte) ([]byte, error) {
	block, err := aes.NewCipher(key)
	if err != nil {
		return nil, err
	}
	gcm, err := cipher.NewGCM(block)
	if err != nil {
		return nil, err
	}
	ciphertext, err := base64.StdEncoding.DecodeString(ciphertextB64)
	if err != nil {
		return nil, errors.New("invalid encoding")
	}
	nonceSize := gcm.NonceSize()
	if len(ciphertext) < nonceSize {
		return nil, errors.New("ciphertext too short")
	}
	nonce, ciphertext := ciphertext[:nonceSize], ciphertext[nonceSize:]
	return gcm.Open(nil, nonce, ciphertext, nil)
}

func secureHandler(w http.ResponseWriter, r *http.Request) {
	apiKeyEncrypted := r.Header.Get("X-Encrypted-Key")
	key := []byte("32-byte-long-key-32-byte-long-key")
	decrypted, err := secureDecryptAEAD(apiKeyEncrypted, key)
	if err != nil {
		// Generic error to avoid leaking information.
		http.Error(w, "unauthorized", http.StatusUnauthorized)
		return
	}
	w.Write(decrypted)
}

func main() {
	r := chi.NewRouter()
	r.HandleFunc("/resource", secureHandler)
	http.ListenAndServe(":8080", r)
}

Second, if you must work with existing encrypted blobs, ensure that padding validation is performed in constant time and that errors are unified. Never expose distinctions between "bad padding" and "bad signature" to the client. A constant-time padding check can be implemented by computing the expected padding value and validating all bytes without early returns based on secret data:

package main

import (
	"crypto/aes"
	"crypto/cipher"
	"errors"
	"io"
	"net/http"
	"time"

	"github.com/go-chi/chi/v5"
)

// Constant-time PKCS7 validation to avoid timing leaks.
func constantTimeValidatePKCS7(data []byte) error {
	if len(data) == 0 {
		return errors.New("invalid data")
	}
	paddingLen := int(data[len(data)-1])
	if paddingLen <= 0 || paddingLen > aes.BlockSize {
		return errors.New("invalid padding")
	}
	// Use a dummy byte to accumulate check without branching on secret.
	var good byte = 1
	for i := len(data) - paddingLen; i < len(data); i++ {
		good &= ^(data[i] ^ byte(paddingLen))
	}
	// Artificial delay to obscure timing differences (not a substitute for proper crypto).
	time.Sleep(1 * time.Millisecond)
	if good != 1 {
		return errors.New("invalid padding")
	}
	return nil
}

// Example middleware using a secure block cipher mode where padding is validated
// in constant time and a single generic error is returned on failure.
func hardenedHandler(w http.ResponseWriter, r *http.Request) {
	apiKeyEncrypted := r.Header.Get("X-Encrypted-Key")
	key := []byte("32-byte-long-key-32-byte-long-key")
	// Assume decryption step produces plaintext with padding.
	// In practice, use an AEAD mode to avoid these concerns.
	plaintext, err := decryptWithCBCAndConstantPaddingCheck(apiKeyEncrypted, key)
	if err != nil {
		http.Error(w, "unauthorized", http.StatusUnauthorized)
		return
	}
	w.Write(plaintext)
}

// Helper to illustrate concept; prefer AEAD in real services.
func decryptWithCBCAndConstantPaddingCheck(ciphertextB64 string, key []byte) ([]byte, error) {
	block, err := aes.NewCipher(key)
	if err != nil {
		return nil, err
	}
	// Decode and split nonce/ciphertext as required by your protocol.
	// This is a placeholder for actual decryption logic.
	// ...
	return nil, errors.New("not implemented: use AEAD instead")
}

func main() {
	r := chi.NewRouter()
	r.HandleFunc("/resource", hardenedHandler)
	http.ListenAndServe(":8080", r)
}

By adopting AEAD and avoiding distinguishable error paths, Chi-based services can eliminate padding oracle risks associated with API key handling. middleBrick scans can identify insecure error handling patterns and missing authentication checks, helping teams validate that their implementation follows these secure patterns.