SLS-5: Broken Access Control

Before you start: make sure you are in the project directory.

cd /workspaces/very-vulnerable-serverless

Theory: What is Broken Access Control?

Access control answers “what are you allowed to do?”. It breaks when a user or service has more permissions than it needs. In AWS this is the IAM role attached to the Lambda: if it is too broad, anyone who steals its credentials gets all that power.

Example: A function that only reads one DynamoDB table but has s3:* on everything. A hacker who takes over the function can now delete every S3 bucket.

Objective

Check the Lambda’s IAM role and see how much more access it has than it needs.

The Lambda function’s IAM role grants s3:* on Resource: "*" — full access to every S3 bucket in the account. The function itself never uses S3.

In the command injection lab, we stole AWS credentials with printenv. Those credentials carry this overpermissive role, giving the attacker access to all S3 buckets — including buckets belonging to other applications in the same account.

Check the IAM configuration:

grep -A4 'statements:' serverless.yml

Output:

statements:
  - Effect: Allow
    Action:
      - s3:*
    Resource: "*"

Impact: A single injection vulnerability chains into full S3 access across the account. The function does not need S3 at all, but the role allows read, write, and delete on every bucket.

Fix: Follow the principle of least privilege. Grant only the specific actions on the specific resources the function needs. If the function does not use S3, remove the IAM statement entirely.

Next step: Security Misconfiguration