【问题标题】:PHP SQL Injection PossibilityPHP SQL 注入的可能性
【发布时间】:2017-07-28 16:22:51
【问题描述】:

我一直在研究用 PHP 编写的 opencart。

如果你看看下面的 php 文件,

https://github.com/opencart/opencart/blob/master/upload/admin/model/customer/customer.php

SQL 语句如下所示

$this->db->query("INSERT INTO " . DB_PREFIX . "customer 
SET customer_group_id = '" . (int)$data['customer_group_id'] . "', 
firstname = '" . $this->db->escape($data['firstname']) . "', 
lastname = '" . $this->db->escape($data['lastname']) . "', 
email = '" . $this->db->escape($data['email']) . "', 
telephone = '" . $this->db->escape($data['telephone']) . "', 
custom_field = '" . $this->db->escape(isset($data['custom_field']) ? json_encode($data['custom_field']) : json_encode(array())) . "', 
newsletter = '" . (int)$data['newsletter'] . "', 
salt = '', 
password = '" . $this->db->escape(password_hash($data['password'], PASSWORD_DEFAULT)) . "', 
status = '" . (int)$data['status'] . "', 
safe = '" . (int)$data['safe'] . "', 
date_added = NOW()");

避免 PHP sql 注入的推荐方法是使用准备好的语句。

我的问题是考虑这个特定代码如何不使用准备好的语句,这个代码是否容易受到 sql 注入的影响?

我不是 php 专家,所以我可能在这里遗漏了一些明显的东西。

编辑:

让我列出我有点担心接受此代码易受攻击的原因。

  1. OpenCart (https://github.com/opencart/opencart) 是一个流行的开源项目,拥有超过 200 个分支。

  2. 它专门用于购物车(电子商务)解决方案,因此开发人员会考虑安全性,并且像这样的 sql 注入是他们首先要检查的事情之一。

  3. 看起来确实是使用$this->db->escape($data['telephone'])完成了某种转义

【问题讨论】:

  • 是的,这段代码很容易受到攻击,因为它没有使用Prepared Statements转义字符串不再是推荐的 SQL 注入解决方案,而且还不够
  • 防止 SQL 注入的唯一确定方法是使用预准备语句。这在许多其他方面也更好 - 避免转义,只需使用准备好的语句。
  • 这不是重复的,请阅读编辑。我知道避免 SQL 注入的推荐方法。但这不是那个。
  • $this->db->escape(isset($data['custom_field']) ? json_encode($data['custom_field']) : json_encode(array())) 读起来很可怕。有关您的具体问题,请参阅security.stackexchange.com/questions/3611/…Always using prepared statements with parameters is something that can be validated by static code analysis tools. A missing call to xxx_escape_string is not spotted that easily and reliably. 如果未来的开发人员将其更改为 safe = '(int)" . $data['safe'] . ",那么您是开放的。

标签: php opencart sql-injection opencart-module opencart2.3


【解决方案1】:

由于所有内容都被转义或转换为整数,我想说它不容易受到 SQL 注入的攻击。

当然,Qirel 在 cmets 中是正确的,即在所有可以想象的方式中,使用准备好的语句是一个更好的解决方案。它更难阅读,并且在将来修改代码时很容易被错误地攻击。

编辑: 经过一番研究,这似乎只有在数据库字符集已正确设置的假设下才是正确的。否则它可能仍然容易受到多字节攻击。

如果在服务器级别设置了不正确的字符集,OpenCart 在使用 MySQL 时似乎很容易受到攻击,因为它使用 SET CHARACTER SET 查询而不是 mysql_real_escape_string。你可以在 Github 上的 latest v3.0.2.0 中看到它。有关详细信息,请参阅 PHP 手册中的MySQL Character sets

我在!5812 中建议修复此特定问题。

【讨论】:

    【解决方案2】:

    您可以预见某些类型的 htmlspecialchars sql 注入,但不是全部。一般正确的方法是使用PHP的data的数据库对象或者CRM/Frameworks的对象自己的资源。

    查看以下链接: http://php.net/manual/pt_BR/pdo.prepare.php https://www.doctrine-project.org/projects/doctrine-dbal/en/2.7/reference/data-retrieval-and-manipulation.html https://framework.zend.com/manual/2.4/en/modules/zend.db.sql.html

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2015-11-27
      • 1970-01-01
      • 1970-01-01
      • 2021-12-06
      • 1970-01-01
      • 1970-01-01
      • 2012-04-25
      • 2014-03-20
      相关资源
      最近更新 更多