目录

使用AWS Lambda Web Functions和DynamoDB构建的反向代理，可以在请求到达应用程序之前检查会话来源、撤销可疑会话，并阻止指定的攻击指纹。所提供的测试报告显示，服务器等待时间的中位数增加了约12 ms，冷启动时则出现了较大延迟。

要点#

  • DynamoDB支持按会话撤销和强一致性读取，不受CloudFront KVS据报存在的5 MB容量限制。
  • 代理可以从登录成功响应中注册会话，无需在应用程序代码中添加数据库调用。
  • 国家或ASN的变化可作为风险信号，JA4和JA4H指纹则为拦截决策提供额外依据。
  • 必须对受保护路由禁用CloudFront缓存，并在代理和应用程序两端拒绝直接访问。

在应用程序前检查请求#

请求路径设为CloudFront → Web Function → 应用程序。Web Function作为区域内的HTTP反向代理运行，在转发受保护请求之前查询DynamoDB。

登录时，保存会话所在国家、可选的ASN以及过期时间。对于后续请求，将CloudFront提供的访问者来源与注册信息进行比较。如果不匹配，可以删除注册信息并重定向到登录页面。这会撤销通过代理的访问权限，但不一定会使应用程序端的原始会话本身失效。

原始实现使用Node.js 24和DynamoDB的强一致性读取，以防止在注册成功后立即读到旧数据。不过，这里的“Impossible Location”指国家或ASN不匹配，并不会计算物理上不可能发生的移动。

正确注册和撤销会话#

明确配置登录路径。仅当响应具有允许的成功状态码，并通过Set-Cookie签发会话Cookie时，才注册会话。切勿注册传入请求中的会话ID。攻击者可能将窃取的Cookie发送到登录端点，尝试替换记录的来源。

应用以下规则。

  • 如果登录时注册失败，返回503，不要返回应用程序的成功响应和会话Cookie。
  • 如果会话查询失败，拒绝访问。在日志和监控中区分基础设施错误与常规登录失败。
  • DynamoDB TTL删除是异步的，因此每次查询时都要检查过期时间，并使注册有效期与应用程序会话的绝对超时时间一致。
  • 注销和来源不匹配时删除注册信息，并确认会话轮换时也会注册新的Cookie。

删除注册信息后，合法用户也需要重新认证。切换移动网络、使用VPN或旅行都可能导致不匹配。先从检查国家开始，在根据ASN变化实施限制之前评估误报情况。

添加基于指纹的拦截#

JA4表示TLS客户端的特征。JA4H表示HTTP请求的结构，包括请求头名称及其顺序。据报告中的实现，CloudFront提供JA4，代理则使用访问者请求头顺序和HTTP版本元数据计算JA4H。为避免依赖会话特有的Cookie值，匹配JA4H的a_b部分。

所提供的测试拦截了从运行于Python 3.13的sqlmap 1.10.10中观测到的指纹。即使将sqlmap的User-Agent修改为类似Firefox的值，报告中的全部90个请求仍返回了403。这说明能够拦截所测试的请求模式，并不意味着能够可靠检测所有sqlmap配置。指纹会发生变化，也可能与合法客户端相同。

在查询会话的同时，使用BatchGetItem查询指纹记录。定义查询失败时允许还是拒绝请求，并在存在UnprocessedKeys时将结果视为不完整。计划应用的规则应先在观察模式下测试，再强制执行。

封堵绕过路径#

原始设计通过CloudFront OAC、IAM认证以及仅限目标分配的资源策略保护Web Function。应用程序则另行通过一个由代理覆盖、由应用程序、ALB或AWS WAF验证的秘密请求头进行保护。安全存储秘密值，并确保轮换期间可以同时使用新旧值。

为受保护路由设置CachingDisabled，因为命中CloudFront缓存会绕过源站侧的代理。明确配置来源和指纹元数据、Cookie、查询字符串及应用程序请求头的转发。还需检查Authorization、Origin和CSRF相关要求。将访问者的Host排除在转发范围之外。对于需要构建公开URL的应用程序，可能还需配置对转发主机信息的信任。

所提供的报告提到，策略的请求头数量上限为10、不支持WebSocket，以及Terraform对Web Functions和Lambda OAC的支持不足。部署前，请通过最新AWS文档确认这些细节、各区域的可用性及认证行为。仅凭所提供的资料，无法独立核实截至2026年10月20日的情况。

将延迟和故障纳入考虑#

东京区域的测试交替切换配置，各发送100个请求，结果显示，不使用代理时服务器等待时间的中位数为51.9 ms，使用代理时为64.4 ms。强一致性会话读取的中位数为3.5 ms，指纹查询为4.4 ms。这些是特定工作负载下的测量值，不构成延迟保证。

据报告，空闲后的首次请求额外耗时1.3～1.5秒。空闲后的首次并发执行中，通过代理的服务器等待时间p99达到335.1 ms，不使用代理时则为96.9 ms。预热状态下的执行有所改善，但尾部延迟仍然较高。

DynamoDB消除了KVS存储容量上限较小的限制，但仍需进行容量规划。应考虑每个受保护请求产生的读取、数据库故障以及跨区域距离。多区域架构还需要明确的一致性设计。不要认为单区域的撤销行为会直接延续到多区域。

下一步#

在预发布环境中部署一个受保护路由，执行“登录 → 来源不匹配 → 使用原始Cookie重试”的测试，确认注册信息已删除，且双方用户都需要重新认证。

来源: https://zenn.dev/cscloud_blog/articles/f4ce99ffeb8ee3

目录