为何含../../../的URL请求会被AWS应用负载均衡器以400状态码拒绝？
我有一个Angular前端应用与.NET后端交互，其中一个端点将用户定义的id作为URL的一部分，即/owner/config/{id}。本地测试一切正常，但部署到AWS ECS后，部分特定id配置的URL请求被拒绝，日志显示请求未转发到目标，是被Application Load Balancer（ALB）拦截。
我已对id部分进行URI编码以处理/等保留字符。启用负载均衡器日志后发现异常：
| id | 日志记录的请求 | 状态码 |
|---|---|---|
| test | GET https://client.mydomain.com:443/owner/config/test HTTP/2.0 | 200 |
| ../../test | GET https://client.mydomain.com:443/owner/config/..%2F..%2Ftest HTTP/2.0 | 200 |
| ../../../test | GET https://client.mydomain.com:443- HTTP/2.0 | 400 |
含两组../的请求正常，但三组时日志中URL子目录部分显示为-并返回400状态码，我确认URL格式正确。负载均衡器监听器规则仅检查Http Host Header匹配client.mydomain.com后转发至目标组，默认规则返回503，该请求未触发默认规则。我已通过Postman测试排除Angular问题，手动将句点编码为%2e也无效果。
原因分析
AWS ALB内置路径遍历防护机制，当检测到编码后的路径遍历序列（如%2e%2e%2f）尝试跳出根目录层级过多时，会触发异常处理逻辑，直接截断请求路径并返回400。从日志看，三组../（编码后为%2e%2e%2f%2e%2e%2f%2e%2e%2f）触发了ALB的安全拦截，导致请求路径被错误处理为https://client.mydomain.com:443-。
可行解决方案
1. 调整API路由设计，改用查询参数传递ID
将id从URL路径参数改为查询参数，示例：
/owner/config?id=../../../test
ALB对查询参数的路径遍历检测宽松度更高，不会触发这类截断问题，后端.NET代码只需调整参数获取方式即可适配，这是最快速且安全的替代方案。
2. 对ID进行自定义编码
不使用标准URI编码，而是对../这类序列做自定义替换，在后端服务中解码还原。例如：
- 前端编码：
../../../test→__dotdot__/__dotdot__/__dotdot__/test - 后端解码：将
__dotdot__还原为..
这种方式完全避开ALB的路径遍历检测逻辑，同时保证ID的正确性。
3. 配置AWS WAF规则放行特定请求（谨慎使用）
若必须保留路径参数设计，可部署AWS WAF并添加自定义规则，允许包含编码后%2e%2e%2f序列的请求通过，同时需限制请求来源、添加其他安全校验，避免引入路径遍历漏洞。
4. 验证ALB目标组的原始路径转发配置
在ALB目标组配置中开启Forward raw query string选项，尝试保留原始编码后的路径部分，但该选项主要针对查询字符串，对路径参数的防护绕过效果有限，需测试验证。
验证建议
优先测试查询参数方案，无需修改ALB或WAF配置，快速解决问题；若坚持路径参数设计，优先选择自定义编码方案，避免修改安全防护规则带来的风险。
内容的提问来源于stack exchange，提问作者Simon Williams
