CWE-134 in APIs

CWE-134, or Uncontrolled Format String, is a critical software weakness where user-supplied input is directly passed as the format string argument to functions like printf(), sprintf(), or similar formatting operations. This allows attackers to read arbitrary memory contents, execute arbitrary code, or cause application crashes.

The weakness occurs when developers mistakenly use user input where a format string should be used. For example, if an application receives a string from an API request and passes it directly to printf("%s", userInput), an attacker could supply format specifiers like "%x" or "%s" to read memory or crash the application.

According to the CWE description, this weakness can lead to information disclosure, denial of service, or even code execution in severe cases. The root cause is the confusion between data and control information—the format string controls how data is interpreted and displayed, so allowing user control over it gives attackers significant power over the application's behavior.

In API development, CWE-134 manifests in several specific ways that developers should watch for. APIs often process user input and generate formatted responses, logs, or error messages. When this processing involves format string functions with user-controlled input, vulnerabilities emerge.

Common API scenarios include:

• Error messages that include user input in format strings
• Logging functions that format user data without proper sanitization
• Response generation that uses user input as format specifiers
• Template engines or message formatting systems
• Database query logging that includes user parameters

Consider an API endpoint that logs requests: log_info("Request from %s: %s", ipAddress, userInput). If userInput contains format specifiers, it could cause the logging function to read adjacent memory or crash.

RESTful APIs are particularly vulnerable because they handle diverse data types and often need to generate human-readable responses or logs. GraphQL APIs face similar risks when formatting query results or error messages. Even microservices architectures can propagate this weakness across service boundaries if one service passes user input to another without proper validation.

Detecting CWE-134 requires both static code analysis and runtime testing. Static analysis tools can identify format string functions and trace data flow from user inputs to format string arguments. However, runtime testing is crucial because it can reveal vulnerabilities that static analysis might miss due to complex control flows or indirect data paths.

middleBrick's API security scanner specifically tests for format string vulnerabilities through several methods:

• Input fuzzing: The scanner sends payloads containing format specifiers like %x, %s, %n, and %% to API endpoints and monitors responses for abnormal behavior
• Memory corruption detection: The scanner looks for signs of memory access violations, crashes, or unexpected output that might indicate format string exploitation
• Response analysis: The scanner examines API responses for leaked memory contents, stack traces, or other indicators that format specifiers were processed
• Log analysis: The scanner checks if error logs or response bodies contain sensitive information that might have been exposed through format string vulnerabilities

During a scan, middleBrick tests each endpoint with various format string payloads and analyzes the behavior. If an endpoint crashes, returns unusual data, or shows signs of memory access when processing format specifiers, it flags this as a potential CWE-134 vulnerability.

Developers can also perform manual testing by sending requests with format string payloads and observing the API's behavior. Tools like curl or Postman can be used to send targeted payloads to test endpoints.

Fixing CWE-134 requires eliminating user control over format strings. The primary remediation strategy is to always use constant format strings and pass user data only as arguments. Here are code examples for different scenarios:

// VULNERABLE - User input controls format string
const message = req.body.message;
console.log(message); // If message contains "%x", it's vulnerable

// SECURE - Constant format string, user data as argument
const message = req.body.message;
console.log("%s", message); // Always safe

For logging functions, always use the proper logging API:

// VULNERABLE
logger.info(userInput); // If userInput contains "%x", vulnerable

// SECURE
logger.info("%s", userInput); // Safe

When generating responses or messages, use template literals or proper string concatenation:

// VULNERABLE
const response = formatString(userInput, data); // If userInput contains format specifiers

// SECURE
const response = `User data: ${userInput}`; // Template literals are safe

For APIs that need to support format-like functionality, implement a whitelist of allowed format specifiers or use a safe templating engine that escapes special characters.

Additional remediation steps:

• Audit all format string function calls in your codebase
• Implement input validation to reject suspicious format specifiers
• Use static analysis tools to catch potential vulnerabilities
• Establish coding standards that prohibit user input in format strings
• Regularly test APIs with format string payloads during security testing

middleBrick's remediation guidance provides specific recommendations based on the detected vulnerability context, helping developers understand exactly how to fix the issue in their particular API implementation.