如何提升SQL层面的防御能力_使用存储过程隐藏表结构-SQL-PHP中文网

存储过程不能真正隐藏表结构。可通过show create procedure或查询information_schema.routines查看定义；若用户有select权限，还能直接查mysql.proc或performance_schema获取源码。

如何提升sql层面的防御能力_使用存储过程隐藏表结构

存储过程真能隐藏表结构吗

不能。调用 SHOW CREATE PROCEDURE 或查询 information_schema.ROUTINES 就能看到定义；如果用户有 SELECT 权限，还能直接查 mysql.proc（旧版本）或通过 performance_schema 获取源码。所谓“隐藏”，只是让普通 SELECT * FROM users 这类直连方式不暴露字段名和关联逻辑，但前提是——你得先剥夺用户对基表的直接访问权限。

必须显式回收用户对底层表的 SELECT、INSERT 等权限，只授予对存储过程的 EXECUTE
MySQL 8.0+ 支持角色（ROLE），建议用角色统一管理权限，避免漏掉某张表
存储过程内部若用动态 SQL（PREPARE/EXECUTE），且拼接了用户输入，反而会放大注入风险

怎么写一个防注入的存储过程参数处理

核心是别让参数进 SQL 字符串拼接。MySQL 不支持参数化查询语句（PREPARE 的 USING 只支持值，不支持列名/表名），所以字段名、排序方向、分页偏移这些不能由用户控制的部分，必须硬编码或白名单校验。

用户可控的值（如搜索关键词、状态码）一律用 IN 参数 + WHERE col = p_keyword 方式，MySQL 会自动做类型绑定
用户想控制排序字段？用 CASE 白名单映射：ORDER BY CASE p_sort_field WHEN 'name' THEN name WHEN 'created_at' THEN created_at ELSE id END
拒绝这种写法：SET @sql = CONCAT('SELECT * FROM t ORDER BY ', p_sort_field) —— 即使加了引号也拦不住 p_sort_field = 'id ASC, (SELECT SLEEP(5))'

为什么用存储过程后还是被拖走全部数据

常见于两类疏漏：

存储过程里用了 SELECT * 且没加 LIMIT，攻击者反复调用就能分页扫库
过程返回结果集过大，而客户端（比如 PHP 的 mysqli_multi_query）默认不设超时或行数限制，导致一次调用拉走百万行
所有返回数据的过程，必须显式加 LIMIT，且上限要根据业务卡死（比如最多 1000 行）
若需导出全量，改用定时任务生成脱敏文件，而非开放实时查询接口
检查 MySQL 的 max_allowed_packet 和应用层连接超时，防止大结果集阻塞连接池

PostgreSQL 或 SQL Server 用户别照搬

MySQL 的存储过程权限模型和 SQL Server 的 EXECUTE AS、PostgreSQL 的 SECURITY DEFINER 函数完全不同。后者可实现真正的“以函数所有者身份执行”，即使调用者无表权限也能查；而 MySQL 的存储过程执行权限检查发生在调用时，且依赖调用者是否具备过程中每条语句所需的权限（除非用 SQL SECURITY DEFINER 并确保 definer 账户权限最小化）。