Nic Ferrier <[EMAIL PROTECTED]> wrote:
__________
>>>> Tim Panton-Westhawk Ltd <[EMAIL PROTECTED]> 17-Oct-00 2:21:31
>PM >>>
>
>>The only things I could come up with
>>were:
>> default demo servlets still installed (eg finger, snoop etc),
>
>Yeah... this probably is a security threat.
>
>
>>I'm not aware of any that pose a real threat.
>
>Not a real threat... but let's make like security consultants and be
>anal.
or hackers...
:-)
>
>
>> ability to run arbitrary servlets, even when they aren't
>explicitly mapped.
>> Eg /servlets/net.ibm.servlets.Mytest
>
>>How many servlet engines support the above form of invocation?
>
>Most.
>
>
>>Do any support it without the servlet needing to be mentioned
>>in a config file? ( this last raises the prospect of invoking
>servlet
>>base classes, or the servlets that underlie jsp's)
>
>Most contains support this...
>
>This form of loading is designed to be config less. The servlet's
>classfile is supposed to be stored in a directory that the container
>knows it can load servlet class files from and no other config
>information is needed.
>
>I suspect that some containers *might* allow any class that has been
>loaded before to be called by this method (because of delegation class
>loaders).
Hmm, like utility classes from jar
from jar files that happen to extend
HttpServlet too. Or do you mean
-arbitrary- classes say
java.util.Vector ... Or worse
net.attglobal.db.Mydbconnection?
>
>That would be a serious security weakness I think... The ability to
>load classes from /servlets/ is a minor security weakness. Some apps
>require it.
>
but I was thinking of non-abstract
base classes which say extend HttpServlet, which are then
extended by 'visible' servlets.
These may not have been written
defensively.
>
>>If I can come up with a useful set of tests, I'll contribute them
>to
>>nessus- an open source vulnerability scanner.
>
>That's a great idea.
Ok, thats on the to-do list then...
T.http://www.westhawk.co.uk/
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
