💻
Application Security Cheat Sheet
  • Application Security Cheat Sheet
  • Android Application
    • Overview
      • Application Data & Files
      • Application Package
      • Application Sandbox
      • Application Signing
      • Deployment
      • Package Manager
    • Intent Vulnerabilities
      • Deep Linking Vulnerabilities
    • WebView Vulnerabilities
      • WebResourceResponse Vulnerabilities
      • WebSettings Vulnerabilities
  • CI/CD
    • Dependency
      • Dependency Confusion
      • Dependency Hijaking
      • Typosquatting
    • GitHub
      • GitHub Actions
      • Code owners
      • Dependabot
      • Redirect
      • Releases
  • Cloud
    • AWS
      • Amazon API Gateway
      • Amazon Cognito
      • Amazon S3
  • Container
    • Overview
      • Container Basics
      • Docker Engine
    • Escaping
      • CVE List
      • Exposed Docker Socket
      • Excessive Capabilities
      • Host Networking Driver
      • PID Namespace Sharing
      • Sensitive Mounts
    • Container Analysis Tools
  • Framework
    • Spring
      • Overview
      • Mass Assignment
      • Routing Abuse
      • SpEL Injection
      • Spring Boot Actuators
      • Spring Data Redis Insecure Deserialization
      • Spring View Manipulation
    • React
      • Overview
      • Security Issues
  • Linux
    • Overview
      • Philosophy
      • File
      • File Descriptor
      • I/O Redirection
      • Process
      • Inter Process Communication
      • Shell
      • Signals
      • Socket
      • User Space vs Kernel Space
    • Bash Tips
  • iOS Application
    • Overview
      • Application Data & Files
      • Application Package
      • Application Sandbox
      • Application Signing
      • Deployment
    • Getting Started
      • IPA Patching
      • Source Code Patching
      • Testing with Objection
  • Resources
    • Lists
      • Payloads
      • Wordlists
    • Researching
      • Web Application
      • Write-ups
    • Software
      • AWS Tools
      • Azure Tools
      • Component Analysis
      • Docker Analysis
      • Dynamic Analysis
      • Fuzzing
      • GCP Tools
      • Reverse Engineering
      • Static Analysis
      • Vulnerability Scanning
    • Training
      • Secure Development
  • Web Application
    • Abusing HTTP hop-by-hop Request Headers
    • Broken Authentication
      • Two-Factor Authentication Vulnerabilities
    • Command Injection
      • Argument Injection
    • Content Security Policy
    • Cookie Security
      • Cookie Bomb
      • Cookie Jar Overflow
      • Cookie Tossing
    • CORS Misconfiguration
    • File Upload Vulnerabilities
    • GraphQL Vulnerabilities
    • HTML Injection
      • base
      • iframe
      • link
      • meta
      • target attribute
    • HTTP Header Security
    • HTTP Request Smuggling
    • Improper Rate Limits
    • JavaScript Prototype Pollution
    • JSON Web Token Vulnerabilities
    • OAuth 2.0 Vulnerabilities
      • OpenID Connect Vulnerabilities
    • Race Condition
    • Server Side Request Forgery
      • Post Exploitation
    • SVG Abuse
    • Weak Random Generation
    • Web Cache Poisoning
Powered by GitBook
On this page
  • Amazon API Gateway overview
  • How API Gateway works
  • Lambda authorizer
  • Security issues
  • Incorrect policyDocument wildcard configuration
  • References
  1. Cloud
  2. AWS

Amazon API Gateway

PreviousAWSNextAmazon Cognito

Last updated 3 years ago

Amazon API Gateway overview

Amazon API Gateway is an AWS service for creating, publishing, maintaining, monitoring, and securing REST, HTTP, and WebSocket APIs at any scale. API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, CORS support, authorization and access control, throttling, monitoring, and API version management. In other words, API Gateway is a scalable and serverless reverse proxy service that can route HTTP/HTTPS requests to different implementation back-ends.

How API Gateway works

The following diagram explains how the API Gateway works:

Lambda authorizer

The following diagram illustrates the authorization workflow for Lambda authorizers:

The execute-api ARN format packs the API ID, API stage, HTTP verb, and the API resource (the URL path) all into the last resource part of the ARN. They are separated by slashes, as if they were forming a single logical path in an imaginary file system.

Wildcard also matches the empty string.

Security issues

Incorrect policyDocument wildcard configuration

The use of wildcards in ANR can lead to the possibility of bypassing access control. Imagine an API that needs to allow a user to access any HTTP verb on a single endpoint /business/op. The developer might be tempted to write the policyDocument as follows:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "execute-api:Invoke",
            "Effect": "Allow",
            "Resource": "anr:aws:execute-api:us-west-1:12345678:myApiId/myStage/*/business/op"
        }
    ]
}

All of the following ARNs would be allowed by the example policy. But item 6 most likely would not be expected by a developer that read this part of the documentation.

So having the HTTP verb as a star makes it so that the endpoint resource is no longer anchored to the beginning of the URL path.

References

(formerly known as a custom authorizer) is an API Gateway feature that uses a lambda function to control access to API. Lambda authorizer is useful for implementing a custom authorization scheme that uses a bearer token authentication strategy such as OAuth or SAML, or that uses request parameters to determine the caller's identity.

When a client makes a request to one of API's methods, API Gateway calls Lambda authorizer, which takes the caller's identity as input and returns an IAM policy as output. has the following structure:

policyDocument property allows the Lambda authorizer to specify which API endpoints this user can or cannot access. policyDocument object contains an IAM policy that allows or denies execution of an execute-api on specially formatted that represent each API endpoint:

The in IAM policies have several different parts separated by colons:

The claim that the API ID, stage name and HTTP verb can be easily replaced by * to mean any value for that part of the resource alone:

Wildcard * is greedy and expands as much as possible inside each of the colon-separated parts of an ARN (it is the equivalent of .* in POSIX regular expressions). The expansion will not stop at the slashes - any * is free to expand its matching into the entire last part of the .

Each AWS service decides whether matching the resource part of ARNs is case sensitive or case insensitive, see .

Lambda authorizer
Output from an Amazon API Gateway Lambda authorizer
action
resources
ARNs
documentation
execute-api ARN
link
Security Implications of AWS API Gateway Lambda Authorizers and IAM Wildcard Expansion
LogoWhat is Amazon API Gateway? - Amazon API GatewayAmazon API Gateway