OData查询参数易引发SQL注入，主因是手动拼接SQL字符串而非参数化处理，尤其在解析$filter、$select、$expand时未校验操作符、字段名或未转义值。
ODATA 本身不执行 SQL，但很多后端实现（比如 ASP.NET Core OData、Apache Olingo、或自研 OData 查询解析器）会把 $filter、$orderby 这类查询参数翻译成底层数据库语句。一旦翻译逻辑用字符串拼接而非参数化方式构造 SQL，就可能引入 SQL 注入风险。
为什么 OData 查询参数容易触发 SQL 注入
典型漏洞出现在「手动解析 OData 表达式树 → 拼接 SQL 字符串」的代码路径中。例如，开发者收到 $filter=name eq 'admin''; DROP TABLE users; --'，未经处理直接插进 "WHERE name = '" + odataFilterValue + "'"，就等于把攻击载荷原样喂给数据库。
- OData 的
$filter支持复杂表达式（eq、contains、substringof、甚至嵌套and/or），解析器若未使用白名单操作符或未对值做转义，极易被绕过 -
$select和$expand若映射到动态列名或表名（如拼接"SELECT " + selectFields + " FROM ..."），也可能导致列名注入 - 部分旧版 OData 库（如早期 Web API 2.x 的
QueryableAttribute）在未启用严格模式时，会对未声明的属性回退到反射+拼接，埋下隐患
ASP.NET Core OData 中必须启用的防护配置
新版 Microsoft.AspNetCore.OData（v8+）默认已禁用不安全行为，但需确认以下三项是否显式设置：
- 禁用自动属性发现：
EnableQueryAttribute(AllowedQueryOptions = AllowedQueryOptions.Filter | AllowedQueryOptions.OrderBy)，避免$select=1;DROP...类攻击利用未限制的选项 - 强制模型绑定验证：在
AddOData配置中调用.Select().Filter().OrderBy().SetMaxTop(100)，并确保model已通过EdmModel显式定义所有可查字段——未注册字段会被直接拒绝，而非尝试反射 - 关闭表达式树到 SQL 的直译开关：若使用
IQueryable直接对接 EF Core，EF Core 本身用参数化查询，但需确认没在中间层用ToString()或ExpressionVisitor手动提取值拼接字符串
自研 OData 解析器如何安全落地
如果你在 Java（Olingo）、Go（go-odata）或 Python（django-odata）中自己写解析器，关键不是“怎么解析”，而是“解析后怎么生成查询”：
- 所有用户输入值（
$filter中的字符串、数字、布尔字面量）必须作为**预编译参数**传入，绝不可拼进 SQL 字符串。例如用PreparedStatement.setObject(1, filterValue)，而不是"WHERE name = '" + value + "'" - 字段名、操作符、函数名（如
startswith、length）必须来自白名单枚举，禁止从请求中直接取用。比如if (!ALLOWED_FUNCTIONS.contains(funcName)) throw new BadRequestException(); - 对
$orderby的字段列表，只允许匹配实体已声明的属性名（可通过反射获取getDeclaredFields()后比对），且排序方向（asc/desc）也需校验，防止注入name asc, (SELECT password FROM users) desc
数据库层兜底：不能只靠应用层过滤
即使 OData 层做了全部防护，仍建议在数据库连接层面加一道锁：
- 为 OData 接口分配专用数据库账号，仅授予
SELECT权限，禁用INSERT、UPDATE、DROP、EXECUTE等任何写操作和 DDL 权限 - 在 SQL Server 或 KingbaseES 上启用 SQL 防火墙（如
kingbase_sql_firewall插件），开启学习模式采集合法 OData 查询模板，后续对非白名单结构的语句直接拦截 - 避免在存储过程中接收 OData 参数并动态 EXEC —— 即便用了
sp_executesql，若参数值参与了对象名拼接（如@table_name），依然危险
最常被忽略的一点：OData 的 $search（全文检索）往往走 CONTAINS 或 to_tsquery，这些函数本身支持语法（如引号、括号、AND/OR），若后端未对搜索关键词做二次转义或封装，就等于把 SQL 元字符直接交给了搜索引擎。别只盯着 $filter。
