Java EE Application Server and Perl scripts

Can a cgi-bin perl script from one WAR access files in another WAR, such as a .properties file??

==== DETAILS I'm putting together a presentation to submit to IT reasons why we should upgrade our internal web server to a real web application server.

If you have read some of my other questions, you'd know that we run Sun Java System Web Server SP9 and RedHat Java 1.4.2. I know this version of Java has been deprecated around 2008. The Sun Server seems to be supported still even though they have a version 7 (although this server doesn't support some newer Java EE technol开发者_C百科ogy.)

I am trying to find security issues with our setup and one issue I can see right now is that as developers, we are told by IT to store database credentials in a provided folder/file that is only readable by the webserver. I demonstrated that I could write both a JSP and cgi perl script to read the DB credentials of the other developer's applications. Therefore they could do the same and read mine. An argument for a real application server is that this issue goes away.

Unless crossContext is true, doesn't a real application server prevent one application from accessing the Class files, JSP and other resources of another WAR??

Will the Application server also prevent perl scripts from doing the same??

I'm looking for anything that supports reasons why IT needs to upgrade.

An app server is actually likely more dangerous than a normal web server.

Typically what will happen in a modern web server, is that when the server executes your CGI code, it'll switch over to the user who owns the code, and thereby adopt it's rights and privileges.

Those privileges combined with permissions will limit what your script can and can not do.

If, for example, your CGI bin scripts can see those of other users, the permissions of those other files may simply be TOO permissive. If you look at their setting, you may well see that they're set to allow anyone to read them. By changing those permissions, the owners of those files can better limit who can and can not do.

With an application server, this is much less likely. All of the applications deployed within the app server (talking generic, off the shelf Java app servers here) all have the same credential for an OS perspective. None of the app servers I'm familiar with demarcate requests or transactions at the user level outside of the user that actually launched the app server.

Typically you have the user that runs the app server, and then you might have a credential for the database pool, but in essence that's it.

The problem now is that once the code starts making file system calls, there's nothing to tell the operating system that the file read call from Application X can not see the files and read them for Application Y. Even though they are separate apps within the app server, they're not separate from the operating systems perspective, and it's the operating system that enforces file level permissions.

Your operators should better configure their web server and the user account default permissions if locking down that kind of access is important to your site.