PHP 的addslashes 是否容易受到sql 注入攻击?
我一直在审阅有关 PHP 的addslashes 函数如何/为何容易受到sql 注入攻击的文章。我读到的所有内容都表明特定的 mysql 编码类型(default-character-set=GBK)存在问题,或者启用 magic_quotes 时存在问题。然而,在这种情况下,我无法突破addslashes()函数并执行一些恶意操作——例如以管理员身份登录。
$user = addslashes($_POST['user']);
$pass = sha1($_POST['pass']);
$sql = "SELECT * FROM admins WHERE user = '".$user."' AND `pass` = '".$pass."'";
$nums = mysql_num_rows(mysql_query($sql));
if($nums==1){
$_SESSION['admin_user'] = $user;
$_SESSION['admin_pass'] = $pass;
这是针对客户的(次要)安全审核,我会建议他们使用 PDO,但我需要显示他们当前的漏洞。
参考文献:
Possible Duplicate:
What does mysql_real_escape_string() do that addslashes() doesn't?
I have been reviewing articles on how/why PHP's addslashes function is vulnerable to sql injection. Everything I have read says there are problems with specific mysql encoding types (default-character-set=GBK), or there are problems if magic_quotes are enabled. However, I have been unable break out of the addslashes() function in this scenario and do something malicious - such as login as an administrator.
$user = addslashes($_POST['user']);
$pass = sha1($_POST['pass']);
$sql = "SELECT * FROM admins WHERE user = '".$user."' AND `pass` = '".$pass."'";
$nums = mysql_num_rows(mysql_query($sql));
if($nums==1){
$_SESSION['admin_user'] = $user;
$_SESSION['admin_pass'] = $pass;
This is a (minor) security audit for a client and I will recommend that they utilize PDO, but I need to display their current vulnerability.
References:
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
Shiflett 在他的博客文章中展示了完整的可利用漏洞。您上面显示的代码似乎没有遵循该示例,因为它没有使用表现出漏洞的字符集。尽管如此,这个洞确实存在。
即使在特定场景中它恰好是安全的,使用 addslashes() 的做法仍然是危险的,Shiflett 的文章应该为您提供足够的材料来争论,即使利用所需的情况非常深奥,并且它们的复制并不完全是微不足道的。
如果您的客户在没有看到其特定系统上的实时漏洞利用的情况下不接受危险,那么他们不值得进行安全审核。
Shiflett shows a full working exploit in his blog entry. The code you show above doesn't seem to be following that example as it's not using the character set that exhibits the vulnerability. Still, the hole definitely exists.
Even if it happens to be safe in the specific scenario, the practice of using
addslashes()
is still dangerous and Shiflett's article should give you enough material to argue with, even though the circumstances the exploit requires are very esoteric, and they're not entirely trivial to reproduce.If your client doesn't accept the danger without seeing a live exploit on their specific system, then they're not worth doing a security audit for.
对于您的特定情况,执行 SQL 注入似乎并不那么容易,但常见的尝试是,如果我输入 unicode null 变量?像
\0
?它会破坏脚本并返回所有内容吗?很可能不会。事实上,您并不总是需要斜杠来执行 SQL 注入。有些 SQL 可能写得非常错误,这里有一个例子
如果
$id
是一个数字,它是完全有效的 SQL,并且你对 $id 执行addslashes
,(谁会这样做无论如何?)。但对于这种特定情况,SQL 注入所需的只是1 OR 1=1
使查询看起来像There is no way
addslashes
ormagic_quotes
> 可以保护你免受这种愚蠢行为的侵害。回到当前的问题,为什么任何头脑正常的人都会使用
GBK
而不是UTF-8
或UTF-16
之类的东西?For your particular case, it does not seem that it is as easy to perform SQL injection, but a common thing to try is something like, if i enter a unicode null variable? like
\0
? Will it break the script and return everything? Most likely not.So thing is, you do not always need slashes to perform SQL injection. Some SQL can be written so horrible wrong, heres an example
If
$id
is a number, its perfectly valid SQL, and you performaddslashes
on $id, (who would do that anyway?). But for this specific case, all you need for SQL injection is1 OR 1=1
making the query look likeThere is no way
addslashes
ormagic_quotes
could protect you against that sort of stupidity.To get back to the question at hand, why would anyone in their right mind ever use
GBK
over something likeUTF-8
orUTF-16
?是的。
根据您链接的文章中提到的条件。
我怀疑你能否显示这个,因为客户端的编码似乎不是著名的GBK。
不过,很可能存在其他可能的漏洞,只是因为人们倾向于滥用转义函数,误认为是错误的。
但我可以向您保证,只要您的客户端编码是单字节一或 UTF-8,并且只要正确使用此函数(如您发布的代码中所示),就不可能进行注入。
Yes.
With the conditions mentioned in the article you linked to.
I doubt you can display this one, as it seems the client's encoding is not the renowned GBK.
Though, there most likely exists other possible vulnerabilities, just because people tend to misuse an escaping function, taking it wrong.
But I can assure you that as long as your client's encoding either single-byte one or UTF-8, and as long as this function used properly (as in the code you posted)- there would be no injection possible.
我不知道为什么你会想使用addslashes而不是mysql_real_escape_string(),但这完全是你的选择,我想。
addslashes() 的作用正如其所言:用斜杠引用字符串
,但是某些 SQL 攻击可以在不使用引号的情况下执行(某些 shell 注入和一些 SQL 盲注)。
出于这个原因,在这种情况下,我个人会使用 mysql_real_escape_string() 而不是 addslashes() 来保护您的数据。
还可以考虑对您的 sql 查询使用 sprintf(),因为它使它更安全:
它使它更安全,因为它不允许除您给出的数据类型之外的任何其他数据类型。
%d = 数字
%s = 字符串,
等等。
我希望这有帮助。
I'm not sure why you would want to use addslashes over mysql_real_escape_string() but that's entirely your choice I suppose.
addslashes() does exactly what it says: Quote string with slashes
But some SQL attacks can be performed without quotes (certain shell injections and some blind SQL injections).
For this reason I would personally use mysql_real_escape_string() over addslashes() for securing your data in THIS case.
Also consider using sprintf() for your sql queries as it makes it slightly more secure:
It makes it more secure as it won't allow any other data-types than the ones that you have given.
%d = digit
%s = string,
etc.
I hope this helps.