Are you sure that the attack was through the GlassFish modules? An
attacker running a script might well be running it entirely outside of
glassfish and (probably) supplying their own code, and thus using the
php/perl script interpreter available on the local server (rather than a
scripting language provided by GlassFish). Even deploying a (say) php
application on GlassFish shouldn't let outside users run their own php
scripts on the server.
Since this sounds like a security issue more than a scripting module
issue, I'd suggest analyzing the vulnerability that was exploited to run
the malicious script and, if the vulnerability is in GlassFish, filing a
high-priority bug against the appropriate component.
glassfish_at_javadesktop.org wrote:
> Thanks Martin, thanks Jacob.
>
> So everything points at the fact that php, perl etc are disabled by default.
> Our web app is a grails application with not a single php or perl script in it; just gsp.
> The thing is that last night the server was attacked and someone managed to run a script of some type with really bad results for us.
> So I want to make sure that we at least eliminate problems with other scripting languages our app is not using.
> Is there a way to really-really be sure?
> I don't like the way some scripting languages are magically enabled or disabled depending on the war file that is deployed. I would like to check and force this by myself, if possible.
>
> If there is no such a way, I guess I'll have to trust the way GlassFish does things internally.
>
> Any further comments will be appreciated
> [Message sent by forum member 'alecaste' (alecaste)]
>
> http://forums.java.net/jive/thread.jspa?messageID=350955
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>