Java EE 应用服务器和 Perl 脚本

Question

一个 WAR 中的 cgi-bin perl 脚本能否访问另一个 WAR 中的文件，例如 .properties 文件？

==== 详情 我正在整理一份演示文稿，向 IT 提交为什么我们应该将内部 Web 服务器升级为真正的 Web 应用程序服务器的原因。

如果您阅读过我的其他一些问题，您就会知道我们运行 Sun Java System Web Server SP9 和 RedHat Java 1.4.2。我知道这个版本的 Java 已经在 2008 年左右被弃用了。Sun 服务器似乎仍然受支持，即使他们有版本 7（尽管这个服务器不支持一些更新的 Java EE 技术。）

我正在尝试查找我们设置的安全问题，我现在可以看到的一个问题是，作为开发人员，我们被 IT 告知将数据库凭据存储在提供的文件夹/文件中，该文件夹/文件只能由网络服务器读取。我演示了我可以编写 JSP 和 cgi perl 脚本来读取其他开发人员应用程序的数据库凭据。因此他们可以做同样的事情并阅读我的。一个真正的应用程序服务器的一个论点是这个问题消失了。

除非crossContext 为真，否则真正的应用服务器不会阻止一个应用程序访问另一个WAR 的Class 文件、JSP 和其他资源吗？

应用服务器是否也会阻止 perl 脚本做同样的事情？

我正在寻找任何支持 IT 需要升级的理由。

Answer 1

应用服务器实际上可能比普通 Web 服务器更危险。

在现代网络服务器中通常会发生的情况是，当服务器执行您的 CGI 代码时，它会切换到拥有该代码的用户，从而采用它的权利和特权。

这些权限与权限相结合将限制您的脚本可以做什么和不能做什么。

例如，如果您的 CGI bin 脚本可以看到其他用户的脚本，则其他文件的权限可能过于宽松。如果您查看它们的设置，您很可能会发现它们设置为允许任何人阅读它们。通过更改这些权限，这些文件的所有者可以更好地限制哪些人可以做，哪些人不能做。

对于应用程序服务器，这种可能性要小得多。部署在应用服务器中的所有应用程序（这里说的是通用的，现成的 Java 应用服务器）都具有相同的操作系统透视图凭据。我熟悉的应用服务器都没有在实际启动应用服务器的用户之外的用户级别划分请求或事务。

通常您拥有运行应用服务器的用户，然后您可能拥有数据库池的凭据，但本质上就是这样。

现在的问题是，一旦代码开始进行文件系统调用，没有什么可以告诉操作系统来自应用程序 X 的文件读取调用无法看到文件并为应用程序 Y 读取它们。即使它们是单独的应用程序在应用服务器中，它们并没有从操作系统的角度分离，而是由操作系统强制执行文件级权限。

如果锁定此类访问权限对您的网站很重要，您的运营商应该更好地配置他们的网络服务器和用户帐户默认权限。