mysql_real_escape_string没有逃避所有类型的"

r3x*_*r3x -1 php mysql

我注意到一些奇怪的mysql_real_escape_string功能.它没有逃脱,或者例如:“TEST”没有被转换成\“TEST\”.

功能正常"(仔细观察,你看它们是不同的)

任何想法如何解决这个问题,我宁愿不从头开始编写这个函数.是否已弃用,是否有替代方案?

编辑:谢谢大家的回答.为了澄清我试图将这个字符串我喜欢的东西"目录\ r \n"插入到数据库中,并且由于某种原因它无法正常工作.一切都适用于任何其他字符串,我没有得到任何错误消息,它只是没有出现在数据库中.所以我认为这可能与".

对我这么容易!

EDIT2

      $interestTable = "5431591 1 Things I Like” <br>";

//problem lies here
        $count = 0;
        $interestTable = preg_replace_callback( '/<br>/', function( $match) use( $tagName, &$count) {
            return $tagName[$count++][0] . ' ' . PHP_EOL;
        }, $interestTable);


    //$interestTable = "5431591 1 Things I Like” catalog \r\n" after format

        $interestTable = mysql_real_escape_string($interestTable);

        echo $interestTable;


        mysql_query("INSERT INTO $tbl_name(userID,storyID,rank, storyType, interestTable)VALUES('$userID','$storyID','$rank','$storyType','$interestTable')", $dbh1);
Run Code Online (Sandbox Code Playgroud)

EDIT3我没有弄错,我把字符串从我喜欢的东西"目录\ r \n"更改为物品我AA目录\ r \n并且它有效.我不知道为什么会发生这种情况,也许在转换为字符串后,某些东西会被编码弄乱,但我不确定.我所知道的肯定,取消后"从字符串,一切工作正常

Pol*_*ial 5

对.永远不要依赖这样的黑名单机制来保障安全.它坏了,可以导致一些有趣的SQL注入:

$query = "SELECT id, title, body FROM posts WHERE id = " . mysql_real_escape_string($_GET['id']);
Run Code Online (Sandbox Code Playgroud)

这仍然可以注入:

1 OR 1=1
Run Code Online (Sandbox Code Playgroud)

导致:

SELECT id, title, body FROM posts WHERE id = 1 OR 1=1
Run Code Online (Sandbox Code Playgroud)

返回所有结果.不相信这是坏事吗?好...

1 OR 1=1 UNION SELECT id, username, password FROM users
Run Code Online (Sandbox Code Playgroud)

哎呦!

为什么这是注射剂?开发人员忘了引用数字ID.如果你能永远看到自己犯这个错误,你应该寻求一个更好的解决方案.


我的建议?停止使用字符串连接,停止使用已弃用的mysql_函数,并使用参数化查询转移到MySQLi或PDO,其中内容与查询语言明确分开.

  • @YourCommonSense是的,但那不是重点**.你能保证你会像这样抓住每一个"陷阱"吗?我测试的几乎所有应用程序都属于SQL注入,因为开发人员忘记了逃避参数,或者不正确地逃脱了它,而**因为他们不知道安全问题.对于MySQLi或PDO来说,它显着*更安全.资料来源:二十年的软件开发,多年的安全研究,渗透测试工作,以及[Sec.SE](http://security.stackexchange.com/)上的30k代表. (6认同)
  • "你也可以使用旧的mysql ext伪造准备好的语句" - 不,这在语义上并非如此.准备好的语句通过在SQL协议层分离数据来工作,从而完全否定了SQL注入攻击的可能性.数据库积极地意识到数据和查询语言之间的差异.任何其他机制只不过是黑名单/过滤技术. (4认同)
  • @YourCommonSense我提出两点:1)黑名单保护从技术角度来看是有缺陷的,因为它实际上并没有阻止注入,2)开发人员会错过像这样的微妙问题.你基本上说"好吧,所以`mysql_real_escape_string`实际上并没有阻止SQL注入,所以让我们使用*不同的*黑名单技术!".这不是解决问题的方法.你提倡用叉子修理"我不能用刀吃汤"的问题,而不是只换成勺子. (3认同)
  • 如果可能的话,我会在@YourCommonSense上投票给你的第一条评论. (3认同)
  • 不知道你正在谈论哪些黑名单.事实上,mysql_real_escape_string与"黑名单"无关,也与保护无关.它只是格式化设施.而且它的工作做得很好.无论如何,正确格式化字符串文字并不是"用刀吃汤".它是任何数据库的常规功能.因此,如果我有一个假的正确格式化字符串文字的伪造语句,它将与使用本机预准备语句一样安全. (2认同)
  • 现在我们已经解决了这个问题,让我们围坐在篝火旁享受一些棉花糖! (2认同)