Integer Overflow in Gorilla Mux with Dynamodb
Integer Overflow in Gorilla Mux with Dynamodb — how this specific combination creates or exposes the vulnerability
In a Go service using Gorilla Mux for routing and DynamoDB as the persistence layer, an integer overflow can occur when user-supplied numeric values (e.g., quantity, limit, or aggregate fields) are parsed into fixed-size integer types before being used to compute request parameters or construct DynamoDB expressions. Gorilla Mux provides route variables as strings; if these are converted to int32 or int64 without validation, a value that exceeds the bit width can wrap, producing a small or negative number that is then passed to DynamoDB operations.
DynamoDB does not cause the overflow, but it can amplify impact: a wrapped integer may be used to compute KeyConditionExpressions, FilterExpressions, or pagination limits, resulting in malformed queries, unexpected scan ranges, or excessive read capacity consumption. For example, a negative value used as a limit may be interpreted as a very large unsigned value by the underlying HTTP layer, causing the request to attempt to process far more items than intended. This can expose sensitive data or degrade performance, aligning with the BFLA/Privilege Escalation and Input Validation checks in middleBrick’s 12 security checks.
Real-world patterns include using URL query parameters like limit or offset extracted by Gorilla Mux, converting them naively with strconv.Atoi, and then embedding them in a DynamoDB Scan or Query. If the input exceeds 2^63-1 (for signed int64) or wraps to a negative number, the resulting expression may bypass intended access controls, violating Property Authorization and exposing data that should be restricted.
middleBrick detects such risks by correlating OpenAPI/Swagger specs (including $ref resolution) with runtime behavior. It flags unsafe conversions, missing range checks on numeric parameters, and usage of potentially tainted values in DynamoDB expression construction, providing findings mapped to OWASP API Top 10 and compliance frameworks. This is distinct from LLM/AI security, but the scanner’s parallel checks ensure the API surface is tested without requiring authentication.
Concrete mitigation in Gorilla Mux involves validating and bounding numeric inputs before they reach DynamoDB, using explicit parsing with overflow detection, and preferring unsigned integers or contextual limits for pagination. Do not rely on DynamoDB to reject invalid parameters; enforce constraints at the handler level to ensure expressions remain safe and predictable.
Dynamodb-Specific Remediation in Gorilla Mux — concrete code fixes
Remediate integer overflow by validating and sanitizing route and query parameters before using them in DynamoDB operations. Use bounded types, explicit overflow checks, and condition builders to ensure expressions stay within expected ranges.
Example 1: Safe limit/offset parsing for DynamoDB Query
import (
"context"
"errors"
"net/http"
"strconv"
"github.com/gorilla/mux"
"github.com/aws/aws-sdk-go-v2/aws"
"github.com/aws/aws-sdk-go-v2/service/dynamodb"
"github.com/aws/aws-sdk-go-v2/service/dynamodb/types"
)
const maxLimit = 1000
func queryHandler(client *dynamodb.Client) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
vars := mux.Vars(r)
pk := vars["pk"]
q := r.URL.Query()
limitStr := q.Get("limit")
offsetStr := q.Get("offset")
limit, err := parsePositiveInt(limitStr, 1, maxLimit)
if err != nil {
http.Error(w, err.Error(), http.StatusBadRequest)
return
}
offset, err := parseNonNegativeInt(offsetStr)
if err != nil {
http.Error(w, err.Error(), http.StatusBadRequest)
return
}
// Build a safe KeyConditionExpression using the validated pk and limit
// offset is handled via pagination token or client-side slicing to avoid expression complexity
kce := &types.Condition{}
// Assume pk is validated elsewhere; construct expression safely
expr := "pk = :pkval"
input := &dynamodb.ScanInput{
TableName: aws.String("Items"),
Limit: aws.Int32(int32(limit)),
// FilterExpression can use validated offset if needed, but prefer pagination tokens
}
// Execute scan with validated limit; use FilterExpression cautiously
_, err = client.Scan(r.Context(), input)
if err != nil {
http.Error(w, "DynamoDB error", http.StatusInternalServerError)
return
}
// Handle response...
}
}
func parsePositiveInt(s string, min, max int) (int, error) {
if s == "" {
return 0, errors.New("parameter is required")
}
val, err := strconv.Atoi(s)
if err != nil {
return 0, errors.New("invalid integer")
}
if val < min || val > max {
return 0, errors.New("parameter out of range")
}
return val, nil
}
func parseNonNegativeInt(s string) (int, error) {
if s == "" {
return 0, nil
}
val, err := strconv.Atoi(s)
if err != nil {
return 0, errors.New("invalid integer")
}
if val < 0 {
return 0, errors.New("parameter must be non-negative")
}
return val, nil
}
Example 2: Bounded numeric input for DynamoDB UpdateItem with condition
import (
"context"
"errors"
"strconv"
"github.com/gorilla/mux"
"github.com/aws/aws-sdk-go-v2/service/dynamodb"
"github.com/aws/aws-sdk-go-v2/service/dynamodb/types"
)
func updateStockHandler(client *dynamodb.Client) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
vars := mux.Vars(r)
itemID := vars["id"]
q := r.URL.Query()
adjustStr := q.Get("adjust")
adjust, err := strconv.Atoi(adjustStr)
if err != nil {
http.Error(w, "invalid adjust parameter", http.StatusBadRequest)
return
}
// Prevent overflow by bounding adjustment to a safe range
const maxAdjustment = 10000
const minAdjustment = -10000
if adjust < minAdjustment || adjust > maxAdjustment {
http.Error(w, "adjustment out of bounds", http.StatusBadRequest)
return
}
// Use UpdateItem with a condition expression that references a validated numeric attribute
// Ensure the new value does not overflow int32 by checking before constructing the update
updateInput := &dynamodb.UpdateItemInput{
TableName: aws.String("Inventory"),
Key: map[string]types.AttributeValue{
"id": &types.AttributeValueMemberS{Value: itemID},
},
UpdateExpression: aws.String("SET quantity = quantity + :adj"),
ConditionExpression: aws.String("quantity + :adj BETWEEN :min AND :max"),
ExpressionAttributeValues: map[string]types.AttributeValue{
":adj": &types.AttributeValueMemberN{Value: strconv.Itoa(adjust)},
":min": &types.AttributeValueMemberN{Value: "0"},
":max": &types.AttributeValueMemberN{Value: "2147483647"}, // safe int32 max
},
}
_, err = client.UpdateItem(r.Context(), updateInput)
if err != nil {
http.Error(w, "update failed", http.StatusInternalServerError)
return
}
w.WriteHeader(http.StatusOK)
}
}
These examples enforce strict bounds and validate inputs before they reach DynamoDB, reducing risk of overflow-related query anomalies. middleBrick’s continuous monitoring (Pro plan) can track such patterns across scans and alert on regressions, while the CLI allows rapid local verification. The GitHub Action can enforce a minimum security score threshold to block deployments with unchecked numeric inputs.