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
