我设计了这个小功能,我想知道是否有人认为它足够安全,或者如果没有,为什么。
function safeSQLI($INPUT){
// Trim un-needed spaces
$safe_input = trim($INPUT);
// Replace any SQL commands
$safe_input = str_ireplace("drop", "", $safe_input);
etc...
// Escape the result
$safe_input = mysql_real_escape_string($safe_input);
// Return the "Safe" result
return $safe_input;
}
答案:不,这根本不安全。我现在正在使用PDO,我想我之前错过了一些很棒的东西。
答案 0 :(得分:3)
str_ireplace()
通常是一个糟糕的选择,因为它不起作用递归。请尝试以下方法:
$safe_input = 'DELDELETEETE * FROM users';
将导致:
DELETE * FROM users
所以,你的整个功能都会回到mysql_real_escape_string()
,之前发生的一切都是无用的。关键是:编写适当的过滤方法并非不可能,但要覆盖每一个案例都是一个真正的挑战。
您希望遵循白名单方法并仅允许某些类型的内容。这在现实世界中很难实现。
或列入黑名单并拒绝某些字符。大多数SQL注入漏洞都会发生,因为可以在字符串中注入其他命令。如果你逃避'
(或使用mysql_real_escape_string(),你通常是安全的)。但是,如果需要额外的过滤,则取决于您的网络应用程序。
或使用准备好的陈述。
答案 1 :(得分:0)
如果你使用你应该使用的引号,它确实可以防止注射:
SELECT * FROM `users` WHERE `name`='$username'
例如。
然而,它完全矫枉过正。只要您使用上述引号,mysql_real_escape_string
就足以使输入安全。
我今天花了一整天的时间试图在已被锁定的服务器上完成一些数据库工作,如果“请求中出现任何看似数据库表名的内容”,则返回“不可接受”的HTTP响应。毋庸置疑,当一个简单的mysql_real_escape_string
已经足够时,它需要的时间比它需要的时间长得多。
答案 2 :(得分:0)
根本不安全。试试这个:
echo safeSQLI("drdropop tatableble TABLE_NAME");
答案 3 :(得分:-1)
永远不会让您在博客中插入关于SQL的帖子。
我认为使用prepare语句和mysql_real_escape_string足够安全。
PS:你可以通过权限来避免BD级别的DDL句子。