我正在努力识别和修复 SQL 注入漏洞。我已经在许多地方转换为 pdo/prepared 语句。
但是，我们有一页看起来像这样：
www.site.com/domain/products/12345/description-of-the-product
在 htaccess 中，这被重写为：
www.site.com/domain/product.php?id=12345
htacess 看起来像这样：
RewriteRule ^(.*)/products/([0-9]+)/([^/\.]+)/?$ /$1/product.php?id=$2 [L]
所以，这是我的问题：由于 url 是用 mod_rewrite 重写的，它只匹配 ingtegers，这是对 sql 注入的某种保护吗？如果您在 URL 中尝试除整数之外的任何其他内容，用户只会收到 404 错误，因为该页面不存在并且 mod_rewrite 没有被激活？
提前致谢。
没有。实际上，也许是这样，但是您应该依赖于防止注入的唯一功能应该是正确转义的代码，如果我们谈论的是通过准备好的语句完成的 SQL 注入。即使这样可能还不够，因为角色的注入可能会导致问题。%
您可以使用任何您想要的验证，并且 URL 的重写可能非常好，但这绝不允许您省略转义查询参数的步骤（希望通过正确参数化的准备语句）。
不，它不会，因为恶意用户可以简单地访问 URL
www.site.com/domain/product.php?id=123'; DROP TABLE products;
并完全绕过你的 mod_rewrite 。尽管只会重写整数，但重写它们以使用的 URL 仍然有效且可访问。每当您进行 SQL 查询时，您都应该使用 PDO 等清理进入查询的每个输入。
不。它使你的 URL 更清晰，但它仍然发送文本信息，在某些时候你的 PHP 代码可以发送到数据库。所以它需要得到保护。
您可以使用mysqli_real_scape_string($_GET['id')或使用如何防止 PHP 中的 SQL 注入？.
不要混淆输入数据验证和 SQL 格式！
这两件事决不能混为一谈。
正确的 SQL 格式不需要任何保护，而仅仅是 SQL 语法规则。而prepared statement是一种可以保证语法正确查询的工具。然而，只有始终如一地无条件地使用它才能发挥作用。