只逃避必要的东西,这是可能的吗?

你考虑过吗 不 在数据到达数据访问层之前对数据进行转义?我问,因为他们对你的团队所采取的方法很在行:

• 如果需要向用户显示表单数据(例如,由于某些验证失败而用错误消息重新显示表单),则需要取消对数据的转义(因为 ' 对HTML不特殊),然后重新转义数据(因为 < 是特殊的)。如果需要向用户显示表单数据 从数据库中提取 ,您不能执行反转义步骤(因为它是由数据库在保存数据时完成的),但仍然必须执行HTML转义步骤。如果您犯了一个错误并执行了错误的过程,那么您会损坏数据,或者更糟,从而导致安全问题。
• 你可以处理来自不同来源的不同格式的问题,通过决定所有通过你的应用程序传递的数据都将被转义。因此,数据访问层将在从数据库中获取数据时重新转义数据。但是,由于应用程序的不同部分需要稍微(或完全)不同的转义,这很快就会导致很多去转义/再转义的胡说八道。从数据库中获取数据,对其进行转义,对其进行反转义,对其进行HTML转义,然后输出。
• 前端表单处理代码必须熟悉数据库。例如,什么是 \' 对你的数据库意味着什么?应该如何 ’ 或 \ 如果真的要逃跑?如果您更改了数据库引擎,甚至更改了它的设置,那么这些设置可能会更改。然后你就可以找到一堆转义/反转义代码。缺少单个转义/反转义可能导致SQL注入。
• 或者,您可以让数据库层执行一个反转义/转义循环,将数据库的知识从前端代码中去掉,从而从应用程序的标准转义序列转换为数据库的转义序列。但这似乎很愚蠢!

还有另一种方法:让需要的任何一个层都能将数据转义出来。数据总是以原始的、未捕获的形式在层之间传递。所以数据访问层执行所有数据库转义。HTML输出代码执行所有HTML转义。当您决定要生成PDF时,您的PDF代码将执行所有PDF转义。

• 现在,当您进行表单输出时,它很清楚要做什么:总是HTML转义数据。不管它来自哪里。千万不要逃跑。
• 现在没有逃逸/逃逸的胡说八道,因为一切都是生吞活剥的。只有在必要的时候才能逃走。
• 前端代码并不关心数据访问层的实现。数据访问层存储并返回任意字符串。
• 你只有 一 在应用程序中查找以确保没有SQL注入问题的位置。
• 您可以轻松地使用数据库驱动程序功能,如占位符。然后,即使数据访问层也不需要知道每个数据库的转义需求;数据库驱动程序会处理它。

如果不知道输入是否已被转义,则无法添加要转义或不转义的自动决策。你可以尝试分析它,但它永远不会是好的,你会遇到双反斜杠对等等。

一旦发送到访问层的数据应该是干净的,并在一个地方处理转义,就做出决定。如果这样做,其他开发人员就不必担心它(他们可能无论如何都不想担心),而且将来迁移到另一个数据库会更容易。它还可以让你随时自由地转移到准备好的声明上。

编辑: 忘了这个:

对输入几乎没有控制力 级别(除非我亲自审查 每个人的代码)

我认为让他们自己发现它是值得的,如果您只是非常清楚地表明转义是属于数据库层的,不应该在其他地方进行的话。

如果我处在你的位置,我就不会懒得不去审查每个人的代码。即使您没有审查用户输入的转义,您仍然可能想看看他们的代码是否有效地完成了。或者,也许不是你来做复习,而是有人来做。

不久前,我经历了一个几乎相似的设置,我们将任务按层划分。一个处理模型,我处理控制器,另一个处理视图。因为我们非常信任每个人,以至于其他人的代码都会按照我们期望的方式工作,所以我们在需要合并它们之前,没有费心检查其他人的代码。在开发后期,我们发现模型中的代码效率低下。它不仅效率低下,而且不起作用!正因为如此,我们不得不彻底检查大量的代码,这会花费我们更多的时间。

我建议您创建一个技术需求规范文档,其中指定了来自用户的可接受输入。此文档后面应该是那些将对接受用户输入的部分进行编码的部分。更好的是,创建单元测试来查看这些需求是否被严格遵守,这样就不必担心它们传递给您的数据是否无效。

另一件事…既然您使用的是PHP,为什么不使用一个好的框架呢?大多数可用的框架都有自己的DAL,您不再需要为转义数据库输入担心太多(好吧,没那么多)。框架应该为您做到这一点。

此外,您可能还需要查看“准备好的语句”。