| 説明 | A vulnerability was identified in evanchiu serverless-todo version 2.0.0. The affected application exposes the AWS API Gateway endpoint POST /api/todos, which is handled by the Lambda function implemented in src/index.js.
The endpoint accepts requests without authentication and processes the complete request body as JSON. After optional Base64 decoding, the application passes the request body directly to JSON.parse(). If the body contains syntactically valid JSON, the resulting JavaScript value is forwarded to the saveTodos() function and stored in Amazon DynamoDB.
The application does not perform sufficient application-level validation before parsing and persisting the submitted data. In particular, it does not enforce a maximum request body size, a maximum number of Todo objects, maximum field lengths, an expected array schema, expected field types, permitted object properties, maximum nesting depth, per-client quotas, or per-user write limits.
The affected request-handling logic obtains the body from event.body. If event.isBase64Encoded is set, the body is decoded using Buffer.from(event.body, "base64").toString(). The complete decoded string is then processed using JSON.parse(). The application only distinguishes between valid and invalid JSON syntax. It does not verify that the parsed value is an array or that each array element represents a valid Todo object.
After parsing, the resulting value is passed directly to saveTodos(). The saveTodos() function constructs an AWS SDK PutCommand containing an item with an id value and a todos property containing the complete attacker-controlled parsed value. The command is then sent to the configured DynamoDB table.
Because the endpoint is unauthenticated, a remote attacker who can reach the deployed API can submit large or high-cardinality JSON documents without possessing a valid user account, access token, API key, or authenticated session.
An attacker may submit an array containing a large number of Todo entries, Todo entries with excessively long title or id fields, objects containing unexpected properties, deeply nested objects or arrays, or other structurally valid JSON values. As long as the payload is valid JSON and remains within infrastructure-level limits, the application attempts to parse and persist it.
Processing such input may consume Lambda CPU time and memory during Base64 decoding, string allocation, JSON parsing, object creation, serialization, logging, and DynamoDB request construction. The resulting DynamoDB operation may consume write capacity or on-demand write resources. Oversized data may also approach or exceed DynamoDB item-size restrictions, causing errors after the application has already spent resources parsing and processing the request.
The issue may also increase CloudWatch logging volume. The application logs information relating to the DynamoDB write operation and includes the Todo value in the logging call. Large attacker-controlled arrays may therefore cause large or repeated log entries, additional log ingestion, increased storage usage, and higher monitoring costs. Logging user-controlled values may also expose submitted content to operators with access to CloudWatch Logs.
The stored payload is persistent. When the application later handles GET /api/todos requests, the previously submitted Todo data may be retrieved and returned to clients. As a result, a successful oversized write may continue to affect later requests by increasing DynamoDB read processing, Lambda response construction, JSON serialization, network transfer, API Gateway response handling, and client-side parsing or rendering.
The vulnerability was validated against an AWS-deployed instance of the application using a single low-volume request. The test did not use concurrent connections, repeated flooding, distributed traffic, or stress-testing techniques.
For validation, a JSON file was generated containing 160 Todo objects. Each object included an id field, a completed boolean field, and a title field containing a unique test marker followed by approximately 1,500 characters. The resulting JSON document was approximately 251,570 bytes.
The payload was submitted to the deployed POST /api/todos endpoint with Content-Type set to application/json. The application returned HTTP 200 and the following response:
{"message":"Success"}
The successful response showed that the request was accepted rather than rejected because of its size, item count, or field lengths.
A subsequent GET request to /api/todos returned content containing the unique test marker. This confirmed that the submitted large Todo array had been persisted and was later retrievable through the application.
CloudWatch Logs also recorded the DynamoDB write path and showed a successful put operation containing the Todo collection. This confirmed that the request reached the Lambda handler, was parsed by the application, was passed to saveTodos(), and resulted in a DynamoDB write operation.
The expected behavior is for the server to validate the request before performing expensive parsing, processing, logging, or database operations. Requests exceeding a defined body-size limit should be rejected with HTTP 413 Payload Too Large. Requests containing an invalid Todo structure should be rejected with HTTP 400 Bad Request.
The endpoint should require the top-level JSON value to be an array. The application should enforce a safe maximum number of Todo entries. Each entry should be required to contain only the permitted fields. The id and title values should be strings with defined maximum lengths, and the completed value should be a boolean. Unknown fields, unexpected value types, excessive nesting, and oversized strings should be rejected.
The actual behavior is that any syntactically valid JSON value is accepted and passed to the DynamoDB persistence function without sufficient schema or resource-bound validation. A payload containing 160 objects and approximately 251 KB of JSON data was accepted, stored, and returned by the application.
The primary security impact is uncontrolled resource consumption. Successful exploitation may increase Lambda execution duration, Lambda memory usage, DynamoDB write activity, DynamoDB read activity, CloudWatch log ingestion, CloudWatch log storage, API Gateway traffic, and overall AWS usage charges.
Repeated requests may create database write pressure, consume available Lambda concurrency, increase throttling, trigger DynamoDB item-size or validation errors, increase application latency, and reduce availability for legitimate users. In environments using usage-based billing, the issue may also allow an unauthenticated attacker to cause financial impact without needing to fully deny service.
The vulnerability is remotely exploitable over the network. Authentication is not required. User interaction is not required. Exploitation complexity is low because the attacker only needs to send a valid JSON request to the exposed endpoint. The degree of availability and financial impact depends on the deployment configuration, API Gateway limits, Lambda concurrency settings, DynamoDB billing mode, AWS WAF configuration, rate limits, monitoring configuration, and the number and frequency of malicious requests.
The issue is categorized as CWE-400, Uncontrolled Resource Consumption. CWE-770, Allocation of Resources Without Limits or Throttling, is also relevant because the application does not impose sufficient limits on the amount of attacker-controlled data processed and stored.
A recommended remediation is to enforce request limits before calling JSON.parse() whenever possible. The application should inspect the encoded and decoded body length and reject requests above a defined maximum. After parsing, it should validate the resulting value against a strict Todo schema before calling saveTodos().
The validation policy should define a maximum request size, a maximum number of Todo entries, maximum id and title lengths, permitted field names, required fields, expected primitive types, and a maximum nesting depth. The application should reject non-array top-level values, unknown properties, arrays exceeding the configured count, strings exceeding configured lengths, and objects containing nested attacker-controlled structures.
Infrastructure-level protections should also be applied as defense in depth. These may include API Gateway request models, API Gateway throttling, usage plans where applicable, AWS WAF rate-based rules, Lambda reserved concurrency, DynamoDB capacity controls, request quotas, monitoring alerts, and cost anomaly detection.
The application should avoid writing complete user-controlled Todo payloads to CloudWatch Logs. Log entries should contain only bounded metadata, such as the number of Todo items, request identifier, validation result, and approximate payload size. Sensitive or attacker-controlled field content should be omitted or redacted. |
|---|