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 Server的版本為7，但仍支持該服務器（盡管該服務器不支持某些較新的Java EE技術。）

我正在嘗試通過設置查找安全問題，現在我可以看到的一個問題是，作為開發人員，IT告訴我們將數據庫憑據存儲在提供的文件夾/文件中，該文件夾/文件僅可由Web服務器讀取。 我證明了我可以同時編寫JSP和cgi perl腳本來讀取其他開發人員應用程序的數據庫憑據。 因此他們可以做同樣的事情並閱讀我的。 真正的應用服務器的一個論點是，這個問題已經消失了。

除非crossContext為true，否則真實的應用程序服務器不會阻止一個應用程序訪問另一個WAR的Class文件，JSP和其他資源嗎？

應用程序服務器還會阻止perl腳本執行相同的操作嗎？

我正在尋找能夠支持IT需要升級的原因的任何東西。

Answer 1

應用服務器實際上可能比普通Web服務器更危險。

通常，在現代Web服務器中將發生的事情是，當服務器執行您的CGI代碼時，它將切換到擁有該代碼的用戶，從而采用它的權利和特權。

這些特權與權限結合在一起將限制腳本可以執行和不能執行的操作。

例如，如果您的CGI bin腳本可以查看其他用戶的腳本，則這些其他文件的權限可能只是TOO允許的。 如果查看它們的設置，您可能會發現它們已設置為允許任何人閱讀它們。 通過更改這些權限，這些文件的所有者可以更好地限制可以做什么和不能做什么。

對於應用服務器，這種可能性要小得多。 在應用服務器內部署的所有應用程序（此處為通用，現成的Java應用服務器）都具有相同的憑據，可用於操作系統。 在實際啟動應用服務器的用戶之外，我都不熟悉在用戶級別划分請求或事務的應用服務器。

通常，您擁有運行應用程序服務器的用戶，然后您可能具有數據庫池的憑據，但實際上就是這樣。

現在的問題是，一旦代碼開始進行文件系統調用，就沒有什么可告訴操作系統了，來自應用程序X的文件讀取調用無法看到文件並為應用程序Y讀取它們。即使它們是應用程序中單獨的應用程序服務器，它們與操作系統沒有分離，而是由操作系統強制執行文件級權限。

如果鎖定這種訪問對您的站點很重要，那么您的運營商應該更好地配置其Web服務器和用戶帳戶的默認權限。