使用AWS Athena查询访问日志时如何防范SQL注入？

核心前提说明 #

首先要明确一个常见认知误区：存储在日志里的SQL注入 payload 本身不会触发Athena注入风险，SQL注入的核心前提是用户可控的内容被拼接进了SQL语句的结构部分，被Athena的解析器识别为执行逻辑才会产生危害。

Athena与CloudFront的默认防护能力 #

• CloudFront侧没有默认防护：它会原样记录所有客户端请求的URI字段，不会主动过滤或转义注入类的特殊字符，payload会完整写入S3的日志文件中。
• Athena侧有基础默认防护：Athena底层基于Presto引擎，默认会严格区分查询语句结构和数据内容，只要你没有手动把日志中的URI内容拼接到查询语句里，只是把URI作为普通字段查询、匹配，引擎会自动把URI内容当做纯字符串数据处理，不会解析其中的SQL语法，默认不会触发注入。

主动加固措施 #

如果你的查询逻辑需要动态传入URI相关的匹配条件，可以通过以下手段完全规避注入风险：

• 所有动态查询必须使用参数化查询：不要手动拼接SQL字符串，所有用户可控的参数（比如要匹配的URI前缀、模糊匹配的关键词）都通过Athena参数化查询的占位符传入，引擎会自动将参数识别为纯数据，不会解析其中的SQL逻辑，这是最有效的防护手段。
• 对URI字段做预处理：可以为CloudFront日志表创建专用查询视图，在视图中通过regexp_replace函数提前转义单引号、分号、反斜杠等SQL特殊字符，进一步降低拼接场景下的风险。
• 最小化权限配置：给运行Athena查询的IAM身份只授予必要的权限，仅开放对应S3日志路径的读权限、Athena工作群的查询权限，不要授予建表、删表、数据写入等额外权限，就算极端情况下出现注入，也能把影响范围降到最低。
• 禁止动态拼接SQL：不要用任何字符串拼接的方式生成Athena查询语句，尤其是不要把从前端、用户输入获取的内容直接拼接到SQL字符串中。

内容的提问来源于stack exchange，提问作者Nicholas Porter