先说说为什么你的注入尝试没成功——从你给出的精简版存储过程来看，它大概率使用了参数化查询，这是目前防御SQL注入最靠谱的机制之一。

当你把data'; DROP TABLE my_table; --作为参数传入时，数据库会把这段内容当成纯文本处理，不会解析成可执行的SQL语句，所以它只会被原封不动插入到表中，不会触发DROP操作。

怎么确认存储过程是不是真的防注入？ #

你可以检查存储过程里的核心执行语句：

• 如果是类似这样的静态参数化SQL：

  UPDATE your_table SET child = @child WHERE ID = @ID
  

  那完全不用担心注入，参数化会把所有输入内容隔离在SQL执行逻辑之外。
• 如果存储过程里用到了动态SQL拼接（比如用EXEC或者sp_executesql把参数拼进SQL字符串），那可能存在风险，但从你给出的代码片段看，这种可能性很低。

进一步的SQL注入测试方法 #

如果你还想验证安全性，可以试试这些测试用例：

• 报错注入测试：输入data' OR 1=1; --，如果是参数化查询，这段内容会直接存入表，不会出现数据库报错；如果存在注入漏洞，可能会抛出语法错误。
• 时间延迟测试：输入data'; WAITFOR DELAY '0:0:5'; --，如果是参数化查询，存储过程会立即执行完成；如果存在漏洞，数据库会延迟5秒才返回结果。
• 布尔盲注测试：输入data' AND (SELECT COUNT(*) FROM sys.tables) > 0; --，观察返回结果是否有差异（如果是参数化，结果不会变；如果有漏洞，可能会根据条件返回不同结果）。

总结 #

你的注入失败基本可以确定是存储过程使用了参数化查询，这已经从根源上阻止了SQL注入。如果存储过程里没有动态SQL拼接的情况，那它的安全性是有保障的。

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