在没有准备好的语句/SQLite/C+的情况下防止SQL注入+；

我希望您能提供一些反馈，说明此方案对SQL注入攻击的安全性

在前端，用户输入个人信息：姓名、地址、电话号码、电子邮件和一些自由格式的文本

后端由C++编写，无框架支持，集成SQLite .<／P> < > C++代码不使用SQLite准备的语句（由于历史原因，现在已经太迟了）。相反，所有SQL语句都构造为printf样式的格式字符串，如下所示：

#define STATEMENT_N "UPDATE members SET FirstName='%s', Surname='%s', DOB='%s', etc"

实际语句是使用手工编码的

sprintf

（

sqlPrintf

）语句创建的，该语句只处理

%s

、

%c

和

%d

转换。然后创建最终语句，如下所示：

sqlPrintf(query_buffer, STATEMENT_N, user_str_1, user_str_2, etc)

因此，换句话说（如果您不熟悉C/sprintf），用户输入将“打印”到

%s

、

%C

和

%d

中。

sqlPrintf

中唯一不明显的处理是用户提供的单引号字符被转义（它们被加倍）

---

这足以防止SQL注入攻击吗？“事先准备好的声明”实际上比上述方案更重要吗？

基本上，这里你唯一需要担心的是单引号。查询中包含在单引号内的任何内容都可以，但单引号可以结束字符串，从而允许其余数据项作为代码运行。如果

sqlPrintf

将单引号对折，您就可以了。阅读关于您的问题的评论，听起来这个系统可以抵御“；--”攻击

双引号足以防止字符串的注入问题。字符串中没有可识别的其他特殊字符。
（请注意，SQLite已经有了。）

---

如果需要处理blob，无论如何都必须使用参数。但这是另一个问题…

防止SQL注入攻击的最佳方法是使用准备好的语句。你似乎知道这一点。将现有应用程序迁移到适当的技术，以完成需要完成的任务。不，这不好。您的类型之一是%s。那只是一根绳子。注入攻击的定义是什么——能够在SQL代码中插入任意字符串。这不提供注射保护。如果您只允许%d，那么您可能就可以了。1。不，这还不够。如果我的名字是

”--？您的代码中没有任何东西可以阻止它被注入，从而清除表中每个人的名字。2.修复它永远不会太迟。3.是的，准备好的语句远不止这些。sqlPrintf

将用户提供的单引号加倍。如果名称是

”--

，则该语句变为

SET FirstName=''；--'-这是个问题吗？我刚刚尝试将名字设置为
”--使用sqlite3，并且不会导致问题（
更新成员集firstname='''；--'其中id=931086
）。它只是像预期的那样设置了名字。很好-谢谢-花了几个小时在文档上，但从未看到过
sqlite3\u xxprintf
的东西。我的
sqlPrintf
是不存在的
sqlite3\u sprintf
和
%q
。遗憾的是，
sqlite3\u snprintf
被破坏了，这使得它的价值有限。顺便说一句，除了
%s
（
%q“
）、
%d
和
%c
，我还没有发现对转换说明符的任何需求。如果我需要处理blob，为什么要使用参数？为什么不直接使用BLOB文本呢？“BLOB文字是包含十六进制数据的字符串文字，前面有一个“x”或“x”字符。例如：x'53514C697465'-没关系。我发现并思考了一些原因。但我想，如果@QF0真的不想使用预先准备好的语句，那么如果需要处理BLOB，他可以使用BLOB文本。