Contents

A reverse proxy built with AWS Lambda Web Functions and DynamoDB can check session origins, revoke suspicious sessions, and block specified attack fingerprints before requests reach the application. The provided test report showed an increase of about 12 ms in median server wait time, with substantial delays during cold starts.

Key Points#

  • DynamoDB supports per-session revocation and strongly consistent reads without the reported 5 MB capacity limit of CloudFront KVS.
  • The proxy can register sessions from successful login responses without adding database calls to application code.
  • Changes in country or ASN can signal risk, while JA4 and JA4H fingerprints provide additional grounds for blocking.
  • CloudFront caching must be disabled for protected routes, and direct access must be denied at both the proxy and the application.

Inspect Requests Before They Reach the Application#

The request path is CloudFront → Web Function → application. The Web Function acts as an HTTP reverse proxy within a region, querying DynamoDB before forwarding protected requests.

At login, store the session’s country, optionally its ASN, and its expiration time. For subsequent requests, compare the viewer’s origin reported by CloudFront with the registered information. If they differ, the proxy can delete the registration and redirect to login. This revokes access through the proxy, but does not necessarily invalidate the underlying application session.

The original implementation uses Node.js 24 and strongly consistent DynamoDB reads. This prevents stale reads immediately after successful registration. However, “Impossible Location” here means a country or ASN mismatch; it does not calculate physically impossible travel.

Register and Revoke Sessions Correctly#

Explicitly configure the login path. Register a session only when the response has an allowed success status and issues a session cookie through Set-Cookie. Never register the session ID from an incoming request. An attacker could send a stolen cookie to the login endpoint to try to replace the recorded origin.

Apply the following rules:

  • If registration at login fails, return 503 and withhold the application’s success response and session cookie.
  • If the session lookup fails, deny access. Distinguish infrastructure errors from ordinary login failures in logs and monitoring.
  • Because DynamoDB TTL deletion is asynchronous, check expiration on every lookup and align the registration’s lifetime with the application session’s absolute timeout.
  • Delete the registration on logout and origin mismatches, and ensure that new cookies are also registered when sessions rotate.

Deleting the registration also requires the legitimate user to reauthenticate. Switching mobile networks, using a VPN, or traveling can cause mismatches. Start with country checks and measure false positives before enforcing restrictions based on ASN changes.

Add Fingerprint Blocking#

JA4 describes TLS client characteristics. JA4H describes the structure of HTTP requests, including header names and their order. In the reported implementation, CloudFront provides JA4, and the proxy calculates JA4H using metadata about the viewer’s header order and HTTP version. Match the a_b portion of JA4H to avoid depending on session-specific cookie values.

The provided tests blocked fingerprints observed from sqlmap 1.10.10 running on Python 3.13. Even after sqlmap’s User-Agent was changed to resemble Firefox, all 90 reported requests returned 403. This shows that the tested request patterns were blocked. It does not establish reliable detection of every sqlmap configuration. Fingerprints can change and may overlap with legitimate clients.

Query fingerprint records with BatchGetItem in parallel with the session lookup. Define whether requests should be allowed or denied if the lookup fails, and treat results as incomplete when UnprocessedKeys are present. Test proposed rules in observation mode before enforcing them.

Close Bypass Paths#

The original design protects the Web Function with CloudFront OAC, IAM authentication, and a resource policy restricted to the target distribution. Protect the application separately with a secret header that the proxy overwrites and the application, ALB, or AWS WAF validates. Store the secret securely and allow both old and new values during rotation.

Set CachingDisabled for protected routes, because a CloudFront cache hit bypasses the origin-side proxy. Explicitly configure forwarding for origin and fingerprint metadata, cookies, query strings, and application headers. Also check requirements for Authorization, Origin, and CSRF. Exclude the viewer’s Host from forwarding. Applications that construct public URLs may also need configuration to trust forwarded host information.

The provided report mentions a policy limit of 10 headers, no WebSocket support, and gaps in Terraform support for Web Functions and Lambda OAC. Before deployment, verify these details, regional availability, and authentication behavior against the latest AWS documentation. The provided materials alone cannot independently confirm the situation as of October 20, 2026.

Account for Latency and Failures#

In tests in the Tokyo region, 100 requests were sent per configuration, alternating between configurations. Median server wait time was 51.9 ms without the proxy and 64.4 ms with it. The median strongly consistent session read took 3.5 ms, and the fingerprint lookup took 4.4 ms. These measurements reflect a specific workload and do not guarantee latency.

The first request after an idle period reportedly incurred an additional 1.3–1.5 seconds. In the first concurrent run after an idle period, p99 server wait time reached 335.1 ms through the proxy, compared with 96.9 ms without it. Warm runs improved performance, but tail latency remained higher.

DynamoDB removes KVS’s small storage limit, but capacity planning is still necessary. Account for reads on every protected request, database failures, and distance between regions. Multi-region configurations also require an explicit consistency design. Do not assume that single-region revocation behavior carries over unchanged.

Next Steps#

Deploy one protected route in staging and run a login → origin mismatch → retry with the original cookie test to confirm that the registration is deleted and both users must reauthenticate.

Source: https://zenn.dev/cscloud_blog/articles/f4ce99ffeb8ee3

Contents