1

我们从网络表单（不受我们控制）中获取输入并将其存储到数据库中。

数据通过 PDO（使用 Zend Db）运行并存储在服务器 A 上的 Mysql 表中，一切都很好，数据按应有的方式转义。

然后，我们有一个夜间例程，它选择前几天的数据，将其导出为 csv，将该 csv ftps 传输到服务器 B，然后将其加载到另一个表中（与服务器 A 上的结构相同）。然后我LOAD DATA IN LOCAL FILE用来拿起 csv 文件并一次性加载它。

我的问题是：我是否正确地假设如果数据在加载到服务器 A 时被正确转义，那么在不再次明确转义的情况下将其大量加载到服务器 B 中仍然是安全的？

（服务器 A 运行 PHP 5.3.7，而服务器 B 运行 5.2.6）

编辑

澄清一下：LOAD DATA IN LOCAL FILE包含在通过 PHP 脚本调用的 sql 查询中，而不是直接的命令行指令（尽管必要时可以这样做）。

4

2 回答 2

1

我是否正确假设如果数据在加载到服务器 A 时被正确转义，它仍然是安全的

不。

像绝大多数 PHP 人一样，您完全误解了“转义”是什么以及它的用途。

  • “转义”根本不会使数据“安全”
  • 逃避与任何“保护”或“注入”无关
  • 转义与“用户输入”或任何数据源无关。
  • 转义与数据无关，因为它是用于查询，而不是数据。

事实上，转义是仅针对一个SQL 文字的格式化规则的唯一部分。一个不起眼的格式化规则，在 PHP 用户的心目中被夸大了。

你真正关心的是什么：

  • 正确的格式，而不是“转义”
  • 不同的 SQL 文字需要不同的格式化规则。您的“转义”，即使持续过去的查询执行，对于字符串旁边的所有查询文字都是无用的。
  • 数据目的地，而不是来源
  • 这样的目的地不是数据库，而只是SQL 查询。格式化永远不会超过查询。

TL;DR：
过去的查询执行没有“转义”，但“转义”并不能保证任何安全。您运行的每个查询都需要正确格式化。
所以，你的假设是错误的。

另外，从上面你可能会说，由于 LOAD DATA IN LOCAL FILE 查询不包含任何数据，所以无论如何都不需要格式化数据，因为格式只需要 SQL 查询，正如我在上面告诉你的，而不是“数据”本身或数据库。

于 2013-06-29T15:42:43.823 回答
0

如果您通过导入数据，LOAD DATA IN LOCAL FILE则已经为您完成了转义。如果您通过不提供下划线转义的 php 扩展插入，则最好转义它。

于 2013-06-29T14:04:17.127 回答