正确保护编辑控件免受 SQL 注入和无意义字符的影响答案

【问题标题】：Properly protect edit control from SQL injection and nonsense characters正确保护编辑控件免受 SQL 注入和无意义字符的影响
【发布时间】：2014-03-20 01:25:51
【问题描述】：

简介及相关资料：

我有一个编辑控件，用户应在其中输入公司名称。编辑控件支持区域设置。

问题：

我希望妥善保护它免受SQL injection 攻击和用户输入无意义字符的影响。

我为解决问题所做的努力：

我正在考虑在我的子类化过程中丢弃 冒号 和 分号 以响应WM_CHAR，并再次执行验证以响应EN_CHANGE。如果出现问题，我会通知用户并禁用“保存”按钮。

由于我的应用程序支持区域设置，因此我需要 区域设置感知 函数来测试输入字符。

到目前为止，我发现 IsCharAlpha 和 IsCharAlphaNumeric 似乎可以识别区域设置（我的英语不是最好的，所以可能我误读了 MSDN 文档，对此我深表歉意）。

我也在这里搜索过类似的问题，但没有找到。

问题：

是否会丢弃 分号 才能解决问题，还是我需要考虑其他一些字符？

我在子类化 + EN_CHANGE 的“正确轨道”上还是有更好的方法来实现这一目标？如果有你能指出我正确的方向吗？

谢谢。

最好的问候。

【问题讨论】：

标签： c++ winapi sql-injection subclassing editcontrol

【解决方案1】：

只有当您使用用户输入动态创建 SQL 语句而不首先验证/转义输入时，才会发生 SQL 注入攻击。不要动态创建 SQL 语句！使用参数化查询或存储过程，则完全没有 SQL 注入的风险。

【讨论】：

我正在使用ADO 和Command Object 来执行参数化查询。我想知道是否应该限制用户输入中的某些字符只是为了更安全？一些不合逻辑的，例如; 或%...根据您的回答，我认为我已经“处于安全的一边”，所以如果无效的字符限制可以给我带来更大的安全性，我很感兴趣？谢谢你的回答。赞成。最好的问候！
参数化查询将为您处理。像; 和% 这样的字符是非常安全的，并且会在不破坏SQL 的情况下按原样发布，因为查询参数将为您处理必要的转义。对于其他字符，例如外语字符，SQL 将因错误而失败，或者更可能字符将根据数据库/字段的配置字符集简单地转换为其他字符。如果要保留用户的输入，则应为数据库使用 Unicode 字符集，并使用 Unicode 字符串提交参数值。