使用boto3的select_object_content查询S3：SQL注入风险与参数化问询

问题1：S3 Select是否存在SQL注入风险？ #

是的，完全存在SQL注入风险。只要你的查询表达式中包含用户可控的输入内容（比如示例中的value是来自用户输入而非硬编码），攻击者就可以构造恶意输入篡改查询逻辑。

举个例子，如果用户输入的value是：' OR 1=1 --，拼接后的SQL表达式会变成：

SELECT * from s3object s where s.field = '' OR 1=1 --'

这会绕过原本的条件限制，返回S3文件中的所有数据。如果查询涉及更敏感的逻辑，注入还可能导致敏感数据泄露或非授权访问。

问题2：能否对S3 Select表达式做参数化？ #

S3 Select目前没有提供像传统关系型数据库那样的内置参数化查询机制（比如%s占位符或命名参数），但可以通过手动转义用户输入的方式来规避注入风险。

核心思路是对用户输入中的特殊SQL字符进行转义，最关键的是处理单引号（SQL字符串的边界符）——将单个单引号替换为两个单引号，这样就能避免攻击者闭合字符串并注入额外逻辑。

示例实现 #

def escape_s3_select_value(value):
    # 处理空值情况
    if value is None:
        return "NULL"
    # 转义单引号并包裹为SQL字符串格式
    return f"'{str(value).replace('''', '''''')}'"

# 假设user_input是用户提供的可控值
user_input = "user's malicious input"
escaped_value = escape_s3_select_value(user_input)

# 拼接安全的查询表达式
expression = f"SELECT * from s3object s where s.field = {escaped_value}"

# 执行查询
resp = self.s3_client.select_object_content(
    Bucket=S3_BUCKET_MAPPING,
    Key=S3_BUCKET_MAPPING_KEY,
    ExpressionType="SQL",
    Expression=expression,
    InputSerialization={
        "CSV": {"FileHeaderInfo": "Use"},
        "CompressionType": "GZIP",
    },
    OutputSerialization={"JSON": {}},
)

额外注意事项 #

• 如果处理的是数值类型，要先验证输入是否为合法数值，避免注入字符串逻辑。
• 尽量通过下拉选择等限制输入范围的方式替代自由输入，从源头降低注入风险。
• 永远不要直接将未处理的用户输入拼接进S3 Select的SQL表达式中。

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