SQS and Lambda SQL Injection

What this lab covers

You enumerate what your access permits, discover the messaging and serverless components behind an application, and place a payload that is executed later by a consumer that trusts its input because it came from an internal queue.

This is the hardest lab in the AWS set and it is rated accordingly. The difficulty is not the injection itself but working out the asynchronous path and confirming execution you cannot observe directly.

It suits experienced testers and serverless architects. Understanding why this evades ordinary testing is worth more than the specific technique.

How second order injection works in serverless architectures

In a second order flaw, input is stored safely and executed unsafely later by a different component. Nothing happens when it is submitted, so testing that observes the immediate response sees nothing, and the vulnerability lives in the relationship between two pieces of code rather than in either one.

A message queue formalises this separation. A producer accepts input and enqueues a message, a consumer processes it, and the two are decoupled by design. That decoupling is the architectural benefit and the security problem, because the consumer receives a message from an internal source and treats it as trusted.

Serverless consumers make the impact broader. The Lambda function processing the message holds an execution role, so injection in the consumer reaches whatever that role permits, and asynchronous execution means the attacker may never see a response to confirm success. Blind confirmation techniques matter more here than in ordinary web testing.

How to detect this in your own environment

Log queue message contents where sensitivity allows, and inspect for payload-shaped input. This is one of the few places where inspecting internal traffic is genuinely useful, because the trust boundary is inside the system.

Monitor consumer errors and duration. Injection attempts frequently produce database errors or unusual execution times in the consumer well before anything succeeds, and those signals are usually collected and never examined.

Alert on the consumer's execution role acting outside its normal pattern, which is where the consequence appears if the injection succeeds.

How to prevent it

Use parameterised queries in the consumer. Validation at the producer is worth doing and is not sufficient, because the consumer must be safe against any message it receives regardless of origin.

Do not treat internal sources as trusted. A message from a queue is input, and the fact that it arrived internally says nothing about where it originated.

Scope the consumer's execution role narrowly, since it determines what a successful injection reaches. A function that writes to one table should be permitted to write to one table.

Real-world context

Second order injection is well known and under-tested, because it defeats the request-and-response model that most scanning and much manual testing relies upon. It survives in mature codebases for exactly that reason.

Event-driven architectures increase the surface. Every queue, topic and event bus is a boundary where one component's output becomes another's input, and each is a place where trust may be assumed rather than verified.

The pattern maps to MITRE ATT&CK T1190 Exploit Public-Facing Application and T1059 Command and Scripting Interpreter.

Applying this at work

• Identify the queues and event sources in your architecture and ask, for each consumer, whether it validates input it receives internally.
• Confirm database access in every consumer uses parameterised queries, not only in internet-facing components.
• Review execution role permissions on functions that process queue messages.
• Collect and actually review consumer errors and duration anomalies.
• Include asynchronous paths in your testing scope, since request-and-response testing will not find them.

Frequently asked questions

What is second order SQL injection?

Injection where the payload is stored during one request and executed later by a different component. The submitting request appears harmless, which is why testing that only observes immediate responses does not find it.

Why do queues make this more likely?

Because they decouple producer and consumer by design, and consumers commonly treat messages as trusted because they arrived internally. That assumption is what turns stored input into executed input.

Where should the fix go?

In the consumer, using parameterised queries. Validating at the producer is worthwhile and insufficient, because the consumer must be safe against any message regardless of how it got there.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS attack and detection paths in full, including IAM abuse and privilege escalation, and is assessed hands-on in a live AWS account.