你应该编码保护你的应用程序免受坏编码器的影响吗？

Question

毫无疑问，我们应该编写应用程序来保护自己免受恶意，好奇和/或粗心的用户的攻击，但是当前和/或未来的同事呢？

例如，我正在编写一个基于Web的API，它接受来自用户的参数。其中一些参数可能映射到配置文件中的值。如果用户使用URL混乱并为参数提供了无效值，则在尝试从配置文件的不存在的部分读取时，我的应用程序将会出错。当然，我在尝试从配置文件中读取之前擦除了params。

现在，如果另外一个开发人员在这个应用程序上运行，那么为此参数添加另一个有效值，该值将通过清理过程，但不会将相应的部分添加到配置文件中。请记住，我只是保护应用程序免受不良用户的攻击，而不是糟糕的程序员。我的申请会失败。

一方面，我知道在转向生产之前应该对所有更改进行测试，这样的事情无疑会出现在一个不错的测试环节中，但另一方面，我尝试构建我的应用程序以抵御失败尽可能。我只是不知道在潜在的失败点列表中包含同事修改我的代码是否“正确”。

对于这个项目，我选择不检查配置文件的相关部分是否存在。作为当前的开发人员，我不允许用户指定会导致失败的参数值，因此我希望未来的开发人员不会将行为引入可能导致失败的生产环境......或者至少消除这样的问题测试期间的案例。

您怎么看？

懒惰......还是哲学上的声音？

Answer 1

“我只是不知道在潜在的失败点列表中包含同事修改我的代码是否”正确“。

阻止同事破坏是不对的。

您不知道您的软件会带来什么新用途。您不知道将来如何修改它。

相反，这样做。

编写简单正确的软件，投入生产，并不再担心某人“破坏”某些东西。

如果您的软件实际上是简单，则其他人可以维护它而不会破坏它。

如果你太复杂了，他们会（a）打破它，无论你做了什么，（b）讨厌让它变得复杂。

所以，尽可能简单地完成这项工作。

Answer 2

听起来你正在采取合理的措施，通过对输入进行一些清理来防止无能。我不相信您有责任防止任何可能滥用您的代码或错误的输入。我会更进一步说，只要你的代码明确记录了什么是可接受的输入，那么你已经做得足够了，特别是如果添加的“idiot错误检查”代码膨胀或（特别是）较慢。

准确记录输入可接受的程序对于内部api是合理的。话虽这么说，我经常在防守上编码（过），但这主要是由于我所处的环境以及我对其余代码的信任程度。

Answer 3

  

懒惰......还是哲学上的声音？

懒惰......傲慢。通过以快速显示错误的方式进行编码，您可以保护应用程序免受您自己的错误，同时防止其他人的错误。每个人都犯了比他们想象的更多的错误。

当然，不是添加更多代码来检测配置文件和参数检查是否匹配，如果参数检查基于配置文件，那么只有一个地方可以添加新值，不一致是不可能的。

Answer 4

我认为未来的开发人员有责任确保她不会在代码中引入错误或失败点。当你从项目中注销时（如果有的话？！），那么签名过程的一部分至少应该是代码尽可能无错误地呈现，这将限制你为未来问题所承担的责任。

如果您的代码保存在版本控制系统中，那么创建一个标记可以标记您移交代码的点是很简单的，这样您就可以将当前代码库与原始代码库进行比较了。一些人可能会试图责怪你的错误（如果这是你来自的角度！），因此允许你证明这是对原始实现所做的更改导致了这些错误。 （当然假设实现确实会导致意外行为，并且不修复“无错误”代码 grin ）。

我过去用来确保数据完整性（并且不是万无一失）的一种方法是检查特定值的特定偏移量的输入，确保输入没有被污染。

希望有所帮助。

Answer 5

从哲学角度讲，这两种方式都很好。我会根据您认为发生这种情况的可能性做出判断。如果你几乎可以肯定有人会以这种方式破坏你的代码，那么提供一个能够在它发生时捕获它的检查可能是礼貌的。

如果看起来不太可能，那么确保他们不破坏代码只是他们工作的一部分。

在任何一种情况下，您的技术说明（或其他适当的文件）都应清楚地表明，当进行一次更改时，还需要进行另一项更改。

Answer 6

我会为未来的开发人员或像我这样的开发人员使用内联注释，这些开发人员在我几个月没有工作之后会忘记应用程序的每个部分发生了什么。

不要担心实际编码以阻止未来的编码员，这是不可能的。只需添加所需的所有信息，以支持或扩展您在源代码上下文中所做的工作。

这是文档，正如Steve B.所说。我只是确保它不是外在的，因为它有迷失的倾向。