>>> Tim Panton-Westhawk Ltd <[EMAIL PROTECTED]> 18-Oct-00 8:23:05
AM >>>
>>Not a real threat... but let's make like security consultants
>>and be anal.
>or hackers...
Crackers... please.
>>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 files that happen to extend
>HttpServlet too. Or do you mean -arbitrary- classes say
java.util.Vector ...
>Or worse net.attglobal.db.Mydbconnection?
No... I mean that a weakness might exist whereby servlet classes
loaded by other means are made available (to service requests) through
the /servlet/ dispatcher.
On reflection I don't think it is a serious risk... but it is a
risk.
>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.
That expressely should NOT happen - if it does it's a security
weakness pointed out by the spec (I can't remember if it's in 2.2 but
I'm sure 2.3 has it).
I think the spec says something like:
containers should not allow classes java.* or javax.servlet.* to be
loaded
from anywhere but the system classloader.
The main servlet container security issues are sandbox issues.
Sandboxes are defined by implementations (apart from the restiction
above I'm not aware of any spec defined sandboxing) and sometimes
configurations - I guess some basic tests to say: "this can be done"
or "that is blocked" might be good but these might require a Java
specific tool no?
Nic
___________________________________________________________________________
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
