我正致力于识别和修复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未被激活？
提前致谢。
答案 0 :(得分：0)
否 的。实际上，也许，但是您应该依赖的仅功能来防止注入应该是正确的转义代码，如果我们谈论的是SQL注入，那将通过准备好的陈述即使这可能还不够，因为注入%字符会导致问题。
您可以使用任何您想要的验证，并且重写URL可能非常好，但这绝不会让您省略转义查询参数的步骤（希望如此）通过适当参数化的准备好的陈述）。
答案 1 :(得分：0)
否它不会，因为恶意用户只能转到网址
www.site.com/domain/product.php?id=123'; DROP TABLE products;
并完全绕过你的mod_rewrite。虽然只会重写整数，但是要重写它们的URL仍然可用且可访问。无论何时进行SQL查询，都应使用PDO等清理当前进入查询的每个输入。
答案 2 :(得分：0)
没有。它使您的URL更清晰，但它仍然发送文本信息，在PHP代码的某些点可以发送到数据库。所以它需要得到保障。
您可以使用mysqli_real_scape_string($_GET['id')或使用How can I prevent SQL injection in PHP?中提到的其他方法来完成此操作。
答案 3 :(得分：0)
不要混淆输入数据验证和SQL格式化！
这两件事永远不应混为一谈。
正确的SQL格式不需要任何保护，只需要SQL语法规则。准备好的语句是一种可以保证语法正确查询的工具。然而，只有始终如一地无条件地使用它，它才能发挥作用。