laj*_*tte 13 security java headless web vulnerabilities
我们有一个小型 Java 应用程序，它使用一些 Camel 路由从网络服务器获取上传的文件，处理它们并发送一些带有结果的电子邮件。
运行此应用程序的服务器已停用。现在我们必须在动力不足的硬件上运行它，因为我无法说服管理员在网络服务器（实际上是一个多用途服务器）上安装 JRE。
我自己是一名 Java 应用程序工程师，我以编写 JEE 代码为生，处理每周价值数万欧元的 B2B 交易。但是我在找到驳斥 java 本身不安全的神话的可靠来源时遇到了问题。
管理员反对安装 JRE 的两个主要论点：
当涉及到占用内存的 Java 应用程序时。嗯...我想说我们必须为 Xmx 设置适当的值。完毕。
现在有很多消息来源在谈论 Java 的许多漏洞。这些来源主要针对运行来自美国雷德蒙德公司的特定操作系统的最终用户。AFAIK 对于配置为自动执行所有小程序的 Java 浏览器插件的未打补丁版本来说可能是真的，很有可能成为驱动感染的受害者。就像在上下班途中与火车上的每个人进行无保护性行为一样有感染性病的风险。
但是我在全球互联网上找不到任何人谈论服务器应用程序或无头运行的 JRE。那完全是另一回事。
或者我在这里遗漏了什么？
[edit 2014-08-28] 澄清：我只关心服务器上的 Java。我不关心 Java 插件和/或用 Java 开发的特定软件的问题。
Fal*_*mot 18
java 为您的环境添加的额外安全表面是复杂的，重要的是不要忽视它或试图将其简化。
首先，JRE 存在安全漏洞的可怕记录。很难指出一个特定的漏洞，这是可怕的部分 - 漏洞绝大多数是具有未指定向量的未指定漏洞。
当我作为安全顾问阅读“允许远程攻击者”之类的条款而没有进一步限定其含义时，我看到这很可能意味着进入某个函数的某些参数可能会调用易受攻击的条件，即使您只运行您编写的代码。而且，由于它们未指明，您无法知道您是否受到影响。
更好的是，Oracle 发布的规范 JRE 对关键更新（包括几乎所有安全更新）有一个规定的季度更新周期。在过去的四年中，他们总共创建了 11 次不循环补丁。这意味着，在您有任何方法修复它之前，您可能会在报告后三个月内容易受到安全漏洞的影响。
java 还有其他问题，我不会在这里讨论，但实际上，似乎有一个合理的担忧，尤其是对于多用途服务器。如果你必须运行这样的东西，你至少应该为它制作一个单一用途的虚拟机，并将它与其他东西隔离开来。
特别是，如果 JRE 中有一个远程允许攻击者获得 RCE，另一个在 PHP 中执行相同的操作，另一个在 Ruby 中执行相同的操作，则您必须修补所有三个。所有这三个似乎都有可能，随着这些事情的发展，攻击者可以选择最方便的那个，然后拥有整个服务器。这就是为什么我们应该使用虚拟机来分离软件，尤其是像托管语言框架这样有缺陷的软件，尤其是那些一年只捆绑四次安全补丁并且是专有的供应商，他们在所有证据面前断言他们是安全。
为了更新，这里有一些我从 ChrisS 的链接 CVE 搜索中挑选出来的 CVE，作为演示。
我最喜欢的，因为我在那里：
顺便说一下，这只是一个小样本。
Java 应用程序占用了我所有的 RAM
使用 RAM 的替代方法是浪费 RAM。您无法保存以备后用。
Java 漏洞百出
这并不重要，因为您不会向全世界公开 JVM。我假设您不会运行任何恶意程序，如果您愿意，Java 比大多数其他语言更安全。重要的是您的应用程序是否存在漏洞。
| 归档时间： |
|
| 查看次数： |
514 次 |
| 最近记录： |