Skip to main content

Traceability Loss - API Gateway

Need​

Enhancement of traceability and logging capabilities in API Gateway

Context​

  • Usage of Terraform for Infrastructure as Code (IaC)
  • Usage of AWS SDK for interacting with Amazon Web Services

Description​

Non compliant code​

provider "aws" {
  region = "us-west-2"
}

resource "aws_api_gateway_rest_api" "my_rest_api" {
  name        = "my_rest_api"
  description = "This is my API for demonstration purposes"
}

resource "aws_api_gateway_stage" "prod" {
  stage_name    = "prod"
  rest_api_id   = aws_api_gateway_rest_api.my_rest_api.id
  deployment_id = aws_api_gateway_deployment.my_deployment.id
}

The above code illustrates an AWS API Gateway setup using Terraform without enabling the logging feature.

The aws_api_gateway_rest_api block creates an API Gateway REST API. The aws_api_gateway_stage block creates a stage for the API, in this case, "prod" (production).

However, in this configuration, the logging feature is not enabled. This means that the API Gateway will not store any logs of its operations.

Logs are crucial for monitoring and debugging purposes. They record the activities within your application and can provide useful insights. They can also be used by other AWS services like CloudWatch to detect potential system anomalies.

Without the logging feature enabled, you might miss critical information about your application's behavior, making it harder to identify and fix issues. This lack of traceability is a system vulnerability.

Steps​

  • Enable the logging feature for the API Gateway instance
  • Set a destination for the log files using AWS CloudWatch or AWS CloudTrail

Compliant code​

provider "aws" {
  region = "us-west-2"
}

resource "aws_api_gateway_rest_api" "my_rest_api" {
  name        = "my_rest_api"
  description = "This is my API for demonstration purposes"
}

resource "aws_api_gateway_stage" "prod" {
  stage_name    = "prod"
  rest_api_id   = aws_api_gateway_rest_api.my_rest_api.id
  deployment_id = aws_api_gateway_deployment.my_deployment.id

  # Enable logging
  access_log_settings {
    destination_arn = aws_cloudwatch_log_group.example.arn
    format          = "$context.identity.sourceIp - - [$context.requestTime] \"$context.httpMethod $context.routeKey $context.protocol\" $context.status $context.responseLength $context.requestId"
  }
}

resource "aws_cloudwatch_log_group" "example" {
  name = "${aws_api_gateway_rest_api.my_rest_api.name}-access-logs"
}

The above code fixes the vulnerability by enabling the logging feature for the API Gateway instance. This is done by adding the access_log_settings block inside the aws_api_gateway_stage resource.

The access_log_settings block has two properties: destination_arn and format.

  • destination_arn is set to the ARN of a CloudWatch Logs group where the access logs will be stored. This is created using the aws_cloudwatch_log_group resource. The name of the log group is set to be the name of the API Gateway instance followed by -access-logs.

  • format is set to a string that specifies the format of the access logs. This string can include a number of different variables that provide information about the request and response. In this case, the format string includes information such as the source IP of the request, the HTTP method used, the route key, the protocol, the status code of the response, the length of the response, and the request ID.

By enabling logging and setting a destination for the log files, you can ensure that all information about requests to and responses from the API Gateway instance is preserved. This information can then be used to detect possible system anomalies.

References​

Last updated on