I just thought I would add my 2 cents worth. An additional security hole that bothers me with the invoker, is the fact that most apps use various "library" jar files in their apps. I seriously doubt that most people scan those jar files looking for any class that implements "servlet". You don't want to have the posibility where someone can invoke a forgotten "diagnostic" servlet that dumps your server configuration.
-----Original Message----- From: Hans Bergsten [mailto:hans@;GEFIONSOFTWARE.COM] Sent: Tuesday, October 22, 2002 2:09 PM To: [EMAIL PROTECTED] Subject: Re: Question on documentation... Paul Copeland wrote: > Hans - below you say: > > "/servlet" default mapping has _never_ been in the spec > > But the Servlets 2.1a Spec (November 1998) has the following under > "Servlet Mapping Techniques" - > > ----- quote ----- > You can map a servlet by using the special URL /servlet/servlet_name. > For example, if you create a servlet with the name listattributes, you > can access the servlet by using the URL /servlet/listattributes. > > You can invoke a servlet by its class name. > For example, if a servlet engine receives a request from the URL > /servlet/com.foo.servlet.MailServlet, the servlet engine can load the > class com.foo.servlet.MailServlet, instantiate it, cast the instance to > a servlet, and then let the servlet handle the request. > ----- end quote ----- Oops, sorry about that. I should have checked the specs before I made that statement. It's interesting, though, that it was allowed in 2.1 (the 2.1 spec doesn't mandate it, just saying that container implementors can support it if they want), because the security issue was reported at least 3 months prior to the release of 2.1 (see below). > So that much was in the spec in 2.1, but it looks like it changed in > 2.2, or am I misunderstanding your comment? Right. I tried to find exactly how the change came about in my spec group mailing list archives, but there's just too much to search through. But if memory serves (this time :-), it was removed from the spec when the mapping rules were formalized in 2.2. Before 2.2, there were no guarantees about any mappings working the same in all containers, even though most containers supported all mappings supported by Java Web Server (JWS). And curiously enough, everyone continued to support the "/servlet" mapping by default, even though it was a known security hole. I'm sure the motivation was "backwards compatibility", and I know some containers (e.g. my LiteWebServer) at least added warnings about it in the documentation. > Also it would be > interesting if you could comment on the security hole created by the > "/servlet" mapping... The first time I saw it reported was in this mail on the JSERV mailing list, July 23, 1998: <http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind9807&L=jserv-interest&P=R50619> Sun issued a security advisory in response, still available here: <http://wwws.sun.com/software/jwebserver/techinfo/security_advisory.html> Basically, with the "/servlet" mapping enabled, you can invoke any servlet in a way it was not intended to be invoked. For instance, you can invoke the servlet that is intended to serve static files (called "file" in the old JWS, called "default" in recent Tomcat containers) with a path to a JSP and get the JSP source file instead of the processed result. You can try this with a default installation of Tomcat 4 prior to 4.0.6/4.1.12, using a URL like: http://<yourserver>/<yourapp>/servlet/default/<path-to-a-JSP-file> With a really bad container, improperly configured (e.g. running as root), you could even fool the "file" servlet to serve files outside the web app, such as the password file for the server and other sensitive files. I'm pretty sure no container allows this today, but at one point it was definitely a risk. So, even though it may be possible to work around these issues in a specific container implementation, the safest approach is to always disable the "invoker" servlet and the "/servlet" mapping, and instead add explicit mappings for all servlets in your application. Over the years, I've seen issues related to the "invoker" pop-up, get resolved, and new issues discovered and plugged, over and over again. To sleep better at nights, just get out of the habit of using "/servlet" URLs and make sure your container is configured to not support it. Hans > ----- Original Message ----- > >> >> Date: Fri, 18 Oct 2002 17:49:22 -0700 >> From: Hans Bergsten <[EMAIL PROTECTED]> >> Subject: Re: Question on documentation... >> >> Luis A wrote: >> >>> Hans, maybe you can help me, >>> >>> Is there a way to restore the unsecure mode? The students have different >>> Servlet names, the broadband access ones have burned CDs for the >>> others, and >>> they have a deadline. I do not think I will have the time needed to >>> read the >>> documentation and instruct a simple patch or mod. What do you think? >> >> >> >> Didn't I say "see the [Tomcat 4.1.12] release notes for details"? If >> you do, you find this: >> >> Starting with Tomcat 4.1.12, the invoker servlet is no longer >> available by default in all webapp. Enabling it for all webapps is >> possible by editing $CATALINA_HOME/conf/web.xml to uncomment the >> "/servlet/*" servlet-mapping definition. >> >> Hans >> >> >>> ----- Original Message ----- >>> From: "Hans Bergsten" <[EMAIL PROTECTED]> >>> To: <[EMAIL PROTECTED]> >>> Sent: Friday, October 18, 2002 8:33 PM >>> Subject: Re: Question on documentation... >>> >>> >>>> Luis A wrote: >>>> >>>> >>>>> Man, you must be kidding. So the tutorial I just wrote and emailed >>>>> to my >>>> >>>> >>> 32 >>> >>> >>>>> students will not work without the web.xml changes? Are you sure? >>>> >>>> >>>> Yes, I'm sure. URL mapping has been in the Servlet spec since 2.0 (and >>>> was an option in JWS before the API was formally specified, I believe), >>>> while the "/servlet" default mapping has _never_ been in the spec (even >>>> though most web containers have supported it for a long time). The >>>> behavior of an "invoker" mapped to a "/servlet" URL was first >>>> identified >>>> as a security risk back in the Servlet 2.0/2.1 days. >>>> >>>> Hans >>>> -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com JavaServer Pages http://TheJSPBook.com =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com DISCLAIMER: The information contained in this e-mail may be confidential and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorized. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator. ==========================================================================To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
