Regex 这个正则表达式模式会捕获所有需要的SQL注入吗？

我们将防火墙规则（REGEX）更改为以下内容：

Name
 Type
 Context
 Severity
 Pattern

CS:select_into
 signature
 http-url
 critical
 .*\[select\]\s+.*\[into\].*

CS:select_from
 signature
 http-url
 critical
 .*\[select\]\s+.*\[from\].*

CS:insert_into
 signature
 http-url
 critical
 .*\[insert\]\s+.*\[into\].*

CS:drop_database
 signature
 http-url
 critical
 .*\[drop\]\s+.*\[database\].*

CS:drop_table
 signature
 http-url
 critical
 .*\[drop\]\s+.*\[table\].*

CS:delete_from
 signature
 http-url
 critical
 .*\[delete\]\s+.*\[from\].*

CS:drop_view
 signature
 http-url
 critical
 .*\[drop\]\s+.*\[view\].*

CS:exec
 signature
 http-url
 critical
 .*\[exec\].*(%28|\().*(%29|\)).*

CS:update_set
 signature
 http-url
 critical
 .*\[update\](%20|\+)(%20|\+|.)*\[set\].*

---

这会阻止所有SQL注入尝试吗？例如，是否可以使用多个空格删除视图？

黑名单是错误的方法。总会有你没有想到的事情，攻击者会想到的

您使用的是什么编程语言/数据库？它们都有向SQL语句传递参数的方法。例如：

String userName = .... ; // from your GET or POST parameter
String sql = "SELECT id FROM user where user_name=?";
ResultSet rs = executeSql(sql, userName);

---

请参见

尝试通过过滤掉某些单词来防止sql注入是行不通的-您总是会错过一些东西，并且尝试查找要涵盖的所有内容会非常耗时

---

您应该看看如何查询数据库——如果您正在动态构建SQL并将来自客户端的值直接连接到语句中，那么这将是一个重要的关注领域——切换到使用参数化SQL/存储过程。存储过程还将为您提供一个附加的安全层，因为您可以授予执行这些过程的权限，而无需对基础表授予直接权限。

您不应该使用regex进行输入筛选

在将输入提交给sql server之前，应该逐个筛选输入

如果插入字符串（或sql语句中撇号之间的任何内容），则应使用sql server的转义函数，该函数将防止任何攻击

如果您的数据是某种类型的数字（整数或浮点），那么您应该检查数据是否真的是一个数字（没有字母就不能执行sql注入）。最好的方法取决于您使用的编程语言，但主要是类型检查或强制类型转换

---

您不应在sql语句中插入任何不受信任的（来自用户的任何内容都是不受信任的）字符串数据，在sql语句中，您不能在其周围放置撇号，如表或列名。

您应确保任何sql仅通过受限权限帐户执行，该帐户除了应用程序明确需要的权限外，没有任何权限，而不是试图捕捉恶意SQL的每一种可能排列。

不，绝对不是！攻击者可能只是发布SQL注入，而不是将其添加到URL中。您是在使用防火墙正则表达式规则从SQL注入中保护数据库吗？你喜欢生活在边缘…；-）抱歉，Í忘了说这是在我们兴奋的安全层之外；）。实际上，这在真正的应用程序中是不可能的。例如，您可能希望您的应用程序能够更新用户的余额。你可能不想让它上当受骗，把余额更新到100万美元。特权限制不会让你这么做。更新应该受到更严格的控制，并且在可能的情况下，在单独认证的帐户下完成。对于可能存在动态sql权限的帐户，不应该有任何作用域来执行OP试图用正则表达式阻止的命令。不应该有超过应用程序要求的最低权限。黑名单只是我们的激励安全的一个附加项。我们已经实施了更多的方法来防止这种类型的黑客行为。我们的一个层是这个层，我们注意到，即使我们有其他安全层，这个层也会阻止某些危险的输入。