删除所有非数字字符是否可以有效转义数据？
在写入 MYSQL dB 之前，我使用此函数从字段中剥离所有非数字：
function remove_non_numeric($inputtext) {return preg_replace("/[^0-9]/","",$inputtext);
这是否有效地转义输入数据以防止 SQL 注入？我可以将此函数包装在 mysql_real_escape_string 中，但认为这可能是多余的。
I use this function to strip all non-numeric from a field before writing to a MYSQL dB:
function remove_non_numeric($inputtext) {return preg_replace("/[^0-9]/","",$inputtext);
Does this effectively escape the input data to prevent SQL Injection? I could wrap this function in mysql_real_escape_string, but thought that might be redundant.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当涉及到 SQL 注入时，假设是所有哔哔声之母。无论如何，将其包装在 mysql_real_escape_string 中。
Assumption is the mother of all bleep when it comes to sql injection. Wrap it in mysql_real_escape_string anyway.
它不会转义数据，但它确实是 OWASP 推荐方法的示例。
通过从输入中删除除数字以外的所有内容，您可以通过实施 白名单来有效防止 SQL 注入。没有任何偏执可以使生成的字符串（在这种特定情况下）成为有效的 SQL 注入有效负载。
但是，代码会老化、发生变化，并且会被误解，因为它是由新开发人员继承的。因此，底线、正确的建议、最重要的就是通过以下 3 个步骤中的一个或多个来积极防止 SQL 注入。按照这个顺序。曾经。单身的。时间。
mysql_real_escape_string属于此类）。mysql_real_escape_string并不是所有反 SQL 注入的答案。它甚至不是最可靠的方法，但它确实有效。剥离除数字以外的所有内容就是将安全值列入白名单，也是一个好主意 - 然而，这两者都不如使用安全 API。It does not escape the data, but it is indeed an example of an OWASP recommended approach.
By removing all but numerics from the input you are effectively protecting against SQL-Injection by implementing a White list. There is no amount of paranoia that can make the resulting string (in this specific case) into an effective SQL Injection payload.
However, code ages, and changes and is misunderstood as it's inherited by new developers. So the bottom line, the correct advice, the end all and be all - is to actively prevent against SQL Injection with one or more of the following 3 steps. In this order. Ever. Single. Time.
mysql_real_escape_stringfalls into this category).mysql_real_escape_stringis not the answer for all anti-sql-injection. It's not even the most robust method, but it works. Stripping all but numerics is white listing the safe values and is also a sound idea - however, neither are as good as using a safe API.