mysql(i)_real_escape_string,可以信赖吗? [英] mysql(i)_real_escape_string, safe to rely on?

查看:62
本文介绍了mysql(i)_real_escape_string,可以信赖吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

function Query()
{
    $args = func_get_args ();

    if (sizeof ($args) > 0)
    {
         $query = $args[0];

         for ($i = 1; $i < sizeof ($args); $i++)
                $query = preg_replace ("/\?/", "'" . mysql_real_escape_string ($args[$i]) . "'", $query, 1);
    }
    else
    {
          return FALSE;
    }

我有这样的功能.基本上,我会这样查询:

I have a function like this. Basically, I make a query like this:

$this->Query('SELECT * FROM USERS WHERE Username = ? AND Points < ?', $username, $points);

它目前支持不推荐使用的mysql函数,但是适应mysqli就像在类中将mysql替换为mysqli一样容易.

It currently supports deprecated mysql functions, but adapting to mysqli will be as easy as replacing mysql with mysqli in my class.

这是抵御SQL注入攻击的安全方法吗?每个问号都会由mysql_real_escape_string自动清除,我以前从未遇到过问题,但是我应该使用mysqli_real_escape_string进行清除吗?

Is this a safe approach to rely on against SQL Injection attacks? Every single question mark is getting sanitized automatically by mysql_real_escape_string and I never had problems before, but should I use mysqli_real_escape_string for sanitization?

我知道有关mysqli的准备好的语句,但是对每个变量使用bindParam似乎对我来说有点矫kill过正.

I know about prepared statements of mysqli but using bindParam for each variable seems a little overkill to me.

您怎么看?

推荐答案

今天真是美好的一天-连续创建明智的数据库抽象层的第二种很好的尝试.

A really great day today - second good attempt to create a sensible database abstraction layer in a row.

我应该使用mysqli_real_escape_string进行清理吗?

should I use mysqli_real_escape_string for sanitization?

否.
只是因为此功能无法清除任何内容.

Nope.
Just because this function doesn't sanitize anything.

但是要格式化 SQL字符串文字,此功能是必须的,不能避免或替换.
因此,您完全正确地使用了此功能,仅格式化字符串并无条件格式化.
因此,只要您可以使用?,您就可以查询完全安全.标记以替换实际数据(并且-使nitpick抱怨空闲-只要您使用mysql(i)_set_charset()函数设置SQL编码).

But to format SQL string literals this function is a must and cannot be avoided or replaced.
So, you are using this function exactly the right way, formatting strings only and formatting them unconditionally.
So, you have you queries perfectly safe, as long as you can use a ? mark to substitute the actual data (and - to make even nitpick complains idle - as long as you set SQL encoding using mysql(i)_set_charset() function).

如果某人称您的方法破了-只是要求他们提供证明代码的完整代码段,以显示该漏洞.

If someone calls your approach broken - just ask them for the complete snippet of proof-code to show the certain vulnerability.

但是,让我将您的注意力吸引到一些重要的事情上.

However, let me draw your attention to a couple of important things.

  1. 动态SQL查询部分仅限于字符串.例如,以下两个查询不适用于您的函数:

  1. Dynamic SQL query parts are not limited to strings only. For example, these 2 queries won't work with your function:

SELECT * FROM table LIMIT ?,?
SELECT * FROM table ORDER BY ?

仅因为数字和标识符需要不同的格式.
因此,最好使用 type-hinted 占位符来告诉您的函数,该应用哪种格式

just because numbers and identifiers require different formatting.
So, it's better to use type-hinted placeholders, to tell your function, which format to apply

请看看我的课程,该课程基于与您的课程相同的原理,但是我上面提到的改进.我希望您会觉得有用或至少值得借一两个想法.

Please, take a look at my class, which built on the very same principle as yours but with improvements I mentioned above. I hope you will find it useful or at least worth to borrow an idea or two.

这篇关于mysql(i)_real_escape_string,可以信赖吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆