Re: Tomcat security handling spec non-compliance
More info:
Pre-existing bug in bugzilla, 10229.
It seems to be a connector issue. As the bug states, I can use the old
org.apache.catalina.connector.http.HttpConnector and get the desired
correct behavior. Since the Coyote Connector is used widely and is the
default, any chance of getting this fixed soon? This happens on both
the HTTP and JkHandler of Coyote.
(I'll go vote on the bug now, if it helps...) :-)
Jeff Tulley ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
>>> [EMAIL PROTECTED] 3/27/03 3:30:40 PM >>>
I think I've found a fairly important place where Tomcat is not spec
compliant. I think there is code in there to make this work, but the
code must have a bug.
The spec part is: SRV 12.5.3, actually in J2EE.12.5.3.1 Login Form
Notes:
..
If the form based login is invoked because of an HTTP request, the
original
request parameters must be preserved by the container for use if, on
successful
authentication, it redirects the call to the requested resource.
..
I have shown that this is not working using the following process:
Create a simple jsp, "formHandler.jsp", put it in a protected app (I
used Tomcat's admin):
<%
String color = request.getParameter("Color");
%>
Your color is: <%=color%>
Create a simple form somewhere outside of there:
If you submit the form while there is a current valid login to the
admin application, your formHandler jsp outputs the correct parameter
information.
If you submit the form while not authenticated to the application, you
are redirected to the login page. After you enter valid credentials,
you
are redirected to the formHandler.jsp, which outputs "Your color is:
null" It has lost the original request parameters even though it
appears
that org.apache.catalina.authenticator.FormAuthenticator,
restoreRequest
tries to restore these.
Can somebody else verify that they see this, and should I submit a
bug?
It seems that this is very important and needs to be fixed.
This is on Tomcat 4.1.18, and I just verified it is still there on
Tomcat 4.1.24
Jeff Tulley ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat security handling spec non-compliance
I think I've found a fairly important place where Tomcat is not spec
compliant. I think there is code in there to make this work, but the
code must have a bug.
The spec part is: SRV 12.5.3, actually in J2EE.12.5.3.1 Login Form
Notes:
...
If the form based login is invoked because of an HTTP request, the
original
request parameters must be preserved by the container for use if, on
successful
authentication, it redirects the call to the requested resource.
...
I have shown that this is not working using the following process:
Create a simple jsp, "formHandler.jsp", put it in a protected app (I
used Tomcat's admin):
<%
String color = request.getParameter("Color");
%>
Your color is: <%=color%>
Create a simple form somewhere outside of there:
If you submit the form while there is a current valid login to the
admin application, your formHandler jsp outputs the correct parameter
information.
If you submit the form while not authenticated to the application, you
are redirected to the login page. After you enter valid credentials, you
are redirected to the formHandler.jsp, which outputs "Your color is:
null" It has lost the original request parameters even though it appears
that org.apache.catalina.authenticator.FormAuthenticator, restoreRequest
tries to restore these.
Can somebody else verify that they see this, and should I submit a bug?
It seems that this is very important and needs to be fixed.
This is on Tomcat 4.1.18, and I just verified it is still there on
Tomcat 4.1.24
Jeff Tulley ([EMAIL PROTECTED])
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/docs tomcat-security-unix.html
glenn 01/06/26 14:01:10 Removed: catalina/docs tomcat-security-unix.html Log: Merged into tomcat-security.html
Re: Tomcat Security
On Fri, 11 May 2001, Benjamin Chad wrote: > Hi, > What security development still needs to be done on Tomcat? Depends on what you mean by "security" :-) If you're talking about authentication -> we need to better integrate tomcat with auth mechanisms in the web server ( that should be part of the connector work ). If you're talking about sandboxing -> testing and a lot of code review is needed For "anti-hacking" -> review of the Static file server, maybe a clean library that would allow servers to get files without beeing tricked by OS ( like case sensitivity, etc). We have some code, but it needs cleanup, review - maybe rewrite. Also: SSL certificate auth is missing ( in 3.3 ). If you need more ideas - just let me know :-) Costin > > I'm in a group at university that needs to find a security software > project. > > Cheers, > Ben. >
RE: Tomcat Security
Hello Ben, A good thorough security audit of Tomcat can be a good project. cheers... -Original Message- From: Benjamin Chad [mailto:[EMAIL PROTECTED]] Sent: Friday, May 11, 2001 11:28 AM To: [EMAIL PROTECTED] Subject: Tomcat Security Hi, What security development still needs to be done on Tomcat? I'm in a group at university that needs to find a security software project. Cheers, Ben.
Tomcat Security
Hi, What security development still needs to be done on Tomcat? I'm in a group at university that needs to find a security software project. Cheers, Ben.
cvs commit: jakarta-tomcat-4.0/catalina/docs tomcat-security-unix.html
glenn 01/02/03 08:41:32
Added: catalina/docs tomcat-security-unix.html
Log:
Implement SecurityManager
Revision ChangesPath
1.1 jakarta-tomcat-4.0/catalina/docs/tomcat-security-unix.html
Index: tomcat-security-unix.html
===
Tomcat SecurityManager setup with Unix
Tomcat SecurityManager setup with Unix
Configuring Tomcat for use with a SecurityManager
Starting Tomcat with a SecurityManager
Trouble shooting catalina.policy configuration and Security
Violations
Configuring Tomcat for use with a SecurityManager
catalina.policy
The security policies implemented by the Java SecurityManager are configured
in the catalina.policy file located in the tomcat conf
directory.
The catalina.policy file replaces any system java.policy
file. The
catalina.policy file can be edited by hand or you can use the
http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/policytool.html">policytool
application
that comes with Java 1.2.
Entries in the catalina.policy file use the standard
java.policy file
format as follows:
// Example policy file entry
grant [signedBy <signer> [,codeBase <code source>] {
permission <class> [<name> [, <action list>]];
};
The signedBy and codeBase entries are optional when granting
permissions. Comment lines begin with // and end at a new line.
The codeBase is in the form of a URL and for a file URL can use the
${java.home} and ${catalina.home} properties which are expanded out to the
directory paths defined for them.
Default catalina.policy file
// == SYSTEM CODE PERMISSIONS =
// These permissions apply to javac
grant codeBase "file:${java.home}/lib/-" {
permission java.security.AllPermission;
};
// These permissions apply to all shared system extensions
grant codeBase "file:${java.home}/jre/lib/ext/-" {
permission java.security.AllPermission;
};
// == CATALINA CODE PERMISSIONS ===
// These permissions apply to the server startup code, and the servlet API
// classes that are shared across all class loaders
grant codeBase "file:${catalina.home}/bin/bootstrap.jar" {
permission java.security.AllPermission;
};
grant codeBase "file:${catalina.home}/bin/servlet.jar" {
permission java.security.AllPermission;
};
grant codeBase "file:${catalina.home}/bin/naming.jar" {
permission java.security.AllPermission;
};
// These permissions apply to the container's core code, plus any additional
// libraries installed in the "server" directory
grant codeBase "file:${catalina.home}/server/-" {
permission java.security.AllPermission;
};
// These permissions apply to all extension libraries (including Jasper,
// if present) installed in the "lib" directory
grant codeBase "file:${catalina.home}/lib/-" {
permission java.security.AllPermission;
};
// == WEB APPLICATION PERMISSIONS =
// These permissions are granted by default to all web applications
// In addition, a web application will be given a read FilePermission
// for all files and directories in its document root.
grant {
permission java.util.PropertyPermission "java.version", "read";
permission java.util.PropertyPermission "java.vendor", "read";
permission java.util.PropertyPermission "java.vendor.url", "read";
permission java.util.PropertyPermission "java.class.version", "read";
permission java.util.PropertyPermission "os.name", "read";
permission java.util.PropertyPermission "os.version", "read";
permission java.util.PropertyPermission "os.arch", "read";
permission java.util.PropertyPermission "file.separator", "read";
permission java.util.PropertyPermission "path.separator", "read";
permission java.util.PropertyPermission "line.separator", "read";
permission java.util.PropertyPermission "java.specification.version", "read";
permission java.util.PropertyPermission "java.specification.
cvs commit: jakarta-tomcat/src/doc/uguide tomcat-security-unix.html
glenn 00/12/28 13:59:19 Added: src/doc/uguide Tag: tomcat_32 tomcat-security-unix.html Log: SecurityManager under unix Revision ChangesPath No revision No revision 1.1.2.1 +197 -0jakarta-tomcat/src/doc/uguide/Attic/tomcat-security-unix.html
