Ruby 的开放式动态类结构（鸭子类型）是否安全？答案

【问题标题】：Is Ruby's open dynamic class structure (duck typing) secure?Ruby 的开放式动态类结构（鸭子类型）是否安全？
【发布时间】：2011-09-28 16:14:18
【问题描述】：

我是一名新晋的 Ruby/Rails 开发人员，拥有多年的 Java 经验。这个“安全”问题是 ruby 特有的——而不是 rails——这就是为什么很难找到答案的原因，因为大多数 rails 安全问题都涉及网络问题。

作为一名 Java 开发人员，我已经阅读了《Effective Java》数次。该书中提出的关键点之一是保护类中的数据和方法免受恶意用户的侵害。我的意思是：尽可能多地将代码私有化，使用不可变类并在返回对不可变对象的引用时使用防御性复制。您也可以使用 final 关键字。

但在 Ruby 中，一切都是开放的。当然，您可以将方法/数据设为私有，但作为 Ruby API 的使用者，有什么阻止我编写自己的方法版本，然后简单地（在运行时或代码中动态地）将其附加到类API？似乎 Effective Java 中讨论的所有安全性根本不适用于 Ruby。这只是从 Java 的思维转变吗？这不是 Ruby 或其他类似语言的“缺陷”吗？

【问题讨论】：

如果您将private 视为安全，那您就完蛋了。听说过反射吗？就像其他所有事情一样，如果攻击者的代码与您的代码在同一进程中，那么您的应用程序就像被劫持一样好。 private等主要是为了语义，让其他代码不用担心实现细节（也让你不用担心其他代码依赖实现细节）。
好的，是的，这和其他人所说的都是有道理的 - 只要有人可以更改您的代码，它是什么语言都没有关系。所以我想我明白了 - 它可以追溯到您可以用来构建类的工具，以表明某些数据受到保护。这样，使用您的代码的人可以减少“错误”，因为事情是可靠构建的，但归根结底，无论语言如何，每个编码人员都可以选择构建适合它们的代码。谢谢大家。

标签： ruby security dynamic duck-typing

【解决方案1】：

防御是针对糟糕的设计，而不是入侵者

封装、类私有功能和其他推荐的 OO 设计模式无法再次防御恶意外来函数和敌对类。

相反，这个想法只是以一种使其不那么脆弱且更容易修改的方式来构建程序。

将每个班级视为一栋独立的建筑。我们可以建一个新办公室，让它靠在北边的下一栋楼上，也许可以从楼里向西延伸一些钢材，以帮助支撑我们的新结构。

明显的结果将是破坏 N 和 W 邻居的结构完整性，以及对新建筑的支持问题。有了软件，像这样的坏主意并不总是那么明显，所以我们阅读了充满原则和建议的书籍来提醒我们。

【讨论】：

【解决方案2】：

为了使其成为攻击媒介，恶意用户必须能够更改您随后将运行的代码。如果他能做到这一点，那么你使用什么语言并不重要：你正在运行他的代码，他拥有你。

【讨论】：