restarting tomcat
I am using the most recent version of Tomcat. *sometimes* when I reload the server during development, it crashes and I need to do a manager/start?path=/ to restart it. Over time these "manager restarts" do not seem to free up the memory as it should. So after several dozen or so reloads, I see that tomcat is taking up almost all of the servers RAM, and not even a manager/start?path=/ will restart the server. We end up needing to completly drop and kickstart tomcat to get that RAM back. We are doing very simple development on a totally dialed-in and updated Solaris box using the latest JDK and JRE. We suspect this is an issue with Tomcats classloader. Any suggestions? Jim Manico VP Software Engineering CodeMagi, Inc. 808-652-3805 cell 801-606-7888 fax [EMAIL PROTECTED]
Adding HTTPONLY cookie support option to Tomcat 5.5/6
Hello, You folks rock - I have used Tomcat at Sun for many projects - it's been rock solid. I'd like to add something back to the community. I'm hot on adding support for the HTTPONLY cookie flag for security purposes now that IE and Tomcat support it for XSS and other security protections. 1) Can I add this to both 5.5 and 6 as a Session Manager option? 2) Where do you recommend I start? 3) Should I post my code samples to the list before I check in? This is my first time contributing to Tomcat, any guidance to get me started would be greatly appreciated. Best, Jim Manico
HTTPOnly session cookie security support
I would like to add HTTPOnly support to the tomcat session handler I added a bugzilla item http://issues.apache.org/bugzilla/show_bug.cgi?id=44382 Thoughts would be greatly apprecited Jim Manico, Senior Application Security Engineer <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] (301) 604-4882 (work) (808) 652-3805 (cell) Aspect SecurityT Securing your applications <http://aspectsecurity.com/about.html> at the source <http://www.aspectsecurity.com> http://www.aspectsecurity.com
Re: Cookies are broken in 6.0.16?
> response.addCookie(new Cookie("test_cookie3", "123===")) looks like
something which should be working.
Honestly, this is not user driven - it's only server programmer driven.
I would dare to say this is either absolutely horrible server side
programming or a possible attempt at a hack/attack and drop the request
altogether. If you really need an equals sign in your cookie data, then
you must URL Encode it. If multiple equal signs appear unencodede, then
it's malformed and should be rejected outright.
- Jim
On Sat, 2008-02-09 at 13:03 +, Mark Thomas wrote:
Maik Jablonski wrote:
Hi,
I've just encountered that Cookies seem to be a little bit broken in
6.0.16. If you want to read a cookie which ends on one or more
equals-sign (=), the equals-signs are removed by Tomcat when the
cookie is read.
Is it a bug or a "undocumented" change?
It is neither. The changes are documented in the change log. As a result of
a couple of minor security issues (see
http://tomcat.apache.org/security-6.html) the cookie handling code has been
tightened up to make it spec compliant.
By default the servlet spec uses version 0 cookies. The name value pairs
are defined as:
NAME=VALUE
This string is a sequence of characters excluding semi-colon, comma and
white space. If there is a need to place such data in the name or value,
some encoding method such as URL style %XX encoding is recommended, though
no encoding is defined or required.
The difficulty here is that although '=' is the delimiter between NAME and
VALUE there is no need to encode it if it appears in the name or the value.
This causes some ambiguities when parsing a header of the form:
Set-Cookie: foo=bar=bartoo
Is the name 'foo' or 'foo=bar'? Is the value 'bar=bartoo' or 'bartoo'?
The changes to the cookie parsing mean the second '=' and any text beyond
it are now ignored.
If you set the cookie version to 1 then the quoting will be applied where
necessary and your example will work as you intend.
It seems to me like an annoying regression. response.addCookie(new
Cookie("test_cookie3", "123===")) looks like something which should be
working. Are you sure there's nothing that could be done about it ?
Maybe some additional encoding for '=' when not quoting ?
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
Filip,
Would you consider auto-encoding only = and ; in the cookie value, but
leaving everything else alone for v0 cookies? Would this possibly pass TCK?
- Jim
no regression, if you do this
c = new javax.servlet.http.Cookie("abcv1","123==");
c.setVersion(1);
response.addCookie(c);
then it works just fine.
however, if you do
c = new javax.servlet.http.Cookie("abcv0","123==");
response.addCookie(c);
then it doesn't. if we encode it, (which we did at our first attempt
for v0 cookies) we actually don't pass the TCK.
only v1 cookies should be double quoted, in previous versions of
tomcat, I believe everything got double quoted, regardless of version
on the cookie.
v0 cookies, the spec says
/NAME/=/VALUE/
This string is a sequence of characters excluding semi-colon, comma
and white space. If there is a need to place such data in the name
or value, some encoding method such as URL style %XX encoding is
recommended, though no encoding is defined or required.
the problem was that encoding wasn't defined nor required. so when we
followed the spec, and added %XX encoding, TCK tests failed.
at this point I would say, we handle cookies correctly. if one needs
== at the end of the cookie, then they need to use v1 cookies,
according to spec
Filip
Remy Maucherat wrote:
On Sat, 2008-02-09 at 13:03 +, Mark Thomas wrote:
Maik Jablonski wrote:
Hi,
I've just encountered that Cookies seem to be a little bit broken in
6.0.16. If you want to read a cookie which ends on one or more
equals-sign (=), the equals-signs are removed by Tomcat when the
cookie is read.
Is it a bug or a "undocumented" change?
It is neither. The changes are documented in the change log. As a
result of
a couple of minor security issues (see
http://tomcat.apache.org/security-6.html) the cookie handling code
has been
tightened up to make it spec compliant.
By default the servlet spec uses version 0 cookies. The name value
pairs
are defined as:
NAME=VALUE
This string is a sequence of characters excluding semi-colon, comma and
white space. If there is a need to place such data in the name or
value,
some encoding method such as URL style %XX encoding is recommended,
though
no encoding is defined or required.
The difficulty here is that although '=' is the delimiter between
NAME and
VALUE there is no need to encode it if it appears in the name or the
value.
This causes some ambiguities when parsing a header of the form:
Set-Cookie: foo=bar=bartoo
Is the name 'foo' or 'foo=bar'? Is the value 'bar=bartoo' or 'bartoo'?
The changes to the cookie parsing mean the second '=' and any text
beyond
it are now ignored.
If you set the cookie version to 1 then the quoting will be applied
where
necessary and your example will work as you intend.
It seems to me like an annoying regression. response.addCookie(new
Cookie("test_cookie3", "123===")) looks like something which should be
working. Are you sure there's nothing that could be done about it ?
Maybe some additional encoding for '=' when not quoting ?
Rémy
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
What about making
//cookies v0
c = new javax.servlet.http.Cookie("abcv0","123==");
response.addCookie(c);
At least throw some kind of malformedCookieData exception instead of
just "failing gracefully" to accelerate programmers ability to upgrade
legacy systems?
- Jim
On Sat, 2008-02-09 at 16:14 -0700, Filip Hanik - Dev Lists wrote:
no regression, if you do this
c = new javax.servlet.http.Cookie("abcv1","123==");
c.setVersion(1);
response.addCookie(c);
then it works just fine.
however, if you do
c = new javax.servlet.http.Cookie("abcv0","123==");
response.addCookie(c);
then it doesn't. if we encode it, (which we did at our first attempt for
v0 cookies) we actually don't pass the TCK.
only v1 cookies should be double quoted, in previous versions of tomcat,
I believe everything got double quoted, regardless of version on the cookie.
v0 cookies, the spec says
/NAME/=/VALUE/
This string is a sequence of characters excluding semi-colon, comma
and white space. If there is a need to place such data in the name
or value, some encoding method such as URL style %XX encoding is
recommended, though no encoding is defined or required.
the problem was that encoding wasn't defined nor required. so when we
followed the spec, and added %XX encoding, TCK tests failed.
at this point I would say, we handle cookies correctly. if one needs ==
at the end of the cookie, then they need to use v1 cookies, according to
spec
I find the regressions caused by the new behavior problematic, and it
will cause lots of problems with existing applications, since the
default cookie version used is version 0.
As I'm the only one complaining at the moment, I think I'll take my
concerns elsewhere, no problem, I get the idea :) Obviously, when I say
"encoding", I am not talking about quoting the whole value (or name) as
was done before.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
> I guess we could throw a run time exception if the value contained
any of those. other than that, I'm not sure how to behave
I think this is the best case scenario for v0 cookies. Perhaps, if you
really want to get fancy, you can add a flag to let legacy solutions
roll back to the old/non-standard cookie handling methodology?
- Jim
Remy Maucherat wrote:
On Sat, 2008-02-09 at 16:14 -0700, Filip Hanik - Dev Lists wrote:
no regression, if you do this
c = new javax.servlet.http.Cookie("abcv1","123==");
c.setVersion(1);
response.addCookie(c);
then it works just fine.
however, if you do
c = new javax.servlet.http.Cookie("abcv0","123==");
response.addCookie(c);
then it doesn't. if we encode it, (which we did at our first attempt
for v0 cookies) we actually don't pass the TCK.
only v1 cookies should be double quoted, in previous versions of
tomcat, I believe everything got double quoted, regardless of
version on the cookie.
v0 cookies, the spec says
/NAME/=/VALUE/
This string is a sequence of characters excluding semi-colon, comma
and white space. If there is a need to place such data in the name
or value, some encoding method such as URL style %XX encoding is
recommended, though no encoding is defined or required.
the problem was that encoding wasn't defined nor required. so when
we followed the spec, and added %XX encoding, TCK tests failed.
at this point I would say, we handle cookies correctly. if one needs
== at the end of the cookie, then they need to use v1 cookies,
according to spec
I find the regressions caused by the new behavior problematic, and it
will cause lots of problems with existing applications, since the
default cookie version used is version 0.
As I'm the only one complaining at the moment, I think I'll take my
concerns elsewhere, no problem, I get the idea :) Obviously, when I say
"encoding", I am not talking about quoting the whole value (or name) as
was done before.
as always, I'm open to suggestions. it'd be easier if you suggested
something.
here is the javadoc for the servlet spec
setValue
public void *setValue*(String
newValue)
Assigns a new value to a cookie after the cookie is created. If you
use a binary value, you may want to use BASE64 encoding.
With Version 0 cookies, values should not contain white space,
brackets, parentheses, equals signs, commas, double quotes, slashes,
question marks, at signs, colons, and semicolons. Empty values may
not behave the same way on all browsers.
*Parameters:*
|newValue| - a |String| specifying the new value
*See Also:*
|getValue()|
,
|Cookie|
I guess we could throw a run time exception if the value contained any
of those. other than that, I'm not sure how to behave
Filip
Rémy
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
> we fixed the cookie behavior in this release due to security issues
filed against the old parsing.
Gotchya, Filip. Makes sense.
What about the Runtime exception? That might at least allow legacy
systems to debug this problem fast. "Fail Quietly" doesn't seem like a
good solution.
- Jim
Jim Manico wrote:
> I guess we could throw a run time exception if the value contained
any of those. other than that, I'm not sure how to behave
I think this is the best case scenario for v0 cookies. Perhaps, if
you really want to get fancy, you can add a flag to let legacy
solutions roll back to the old/non-standard cookie handling methodology?
no, we wont do that. we fixed the cookie behavior in this release due
to security issues filed against the old parsing.
Filip
- Jim
Remy Maucherat wrote:
On Sat, 2008-02-09 at 16:14 -0700, Filip Hanik - Dev Lists wrote:
no regression, if you do this
c = new javax.servlet.http.Cookie("abcv1","123==");
c.setVersion(1);
response.addCookie(c);
then it works just fine.
however, if you do
c = new javax.servlet.http.Cookie("abcv0","123==");
response.addCookie(c);
then it doesn't. if we encode it, (which we did at our first
attempt for v0 cookies) we actually don't pass the TCK.
only v1 cookies should be double quoted, in previous versions of
tomcat, I believe everything got double quoted, regardless of
version on the cookie.
v0 cookies, the spec says
/NAME/=/VALUE/
This string is a sequence of characters excluding semi-colon,
comma
and white space. If there is a need to place such data in the
name
or value, some encoding method such as URL style %XX encoding is
recommended, though no encoding is defined or required.
the problem was that encoding wasn't defined nor required. so when
we followed the spec, and added %XX encoding, TCK tests failed.
at this point I would say, we handle cookies correctly. if one
needs == at the end of the cookie, then they need to use v1
cookies, according to spec
I find the regressions caused by the new behavior problematic, and it
will cause lots of problems with existing applications, since the
default cookie version used is version 0.
As I'm the only one complaining at the moment, I think I'll take my
concerns elsewhere, no problem, I get the idea :) Obviously, when I
say
"encoding", I am not talking about quoting the whole value (or
name) as
was done before.
as always, I'm open to suggestions. it'd be easier if you suggested
something.
here is the javadoc for the servlet spec
setValue
public void *setValue*(String
<http://java.sun.com/j2se/1.5/docs/api/java/lang/String.html> newValue)
Assigns a new value to a cookie after the cookie is created. If you
use a binary value, you may want to use BASE64 encoding.
With Version 0 cookies, values should not contain white space,
brackets, parentheses, equals signs, commas, double quotes, slashes,
question marks, at signs, colons, and semicolons. Empty values may
not behave the same way on all browsers.
*Parameters:*
|newValue| - a |String| specifying the new value
*See Also:*
|getValue()|
<http://java.sun.com/javaee/5/docs/api/javax/servlet/http/Cookie.html#getValue%28%29>,
|Cookie|
<http://java.sun.com/javaee/5/docs/api/javax/servlet/http/Cookie.html>
I guess we could throw a run time exception if the value contained
any of those. other than that, I'm not sure how to behave
Filip
Rémy
-
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]
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
> The security issue only exists because of a fundamentally broken servlet in the examples, and assumes the user will click on a URL. That's not what I call a security problem. There is a whole class of security problems that are driven by bad server code and user interaction, such as reflective XSS due to poor input validation. Low risk as Filip saz, but a security problem none-the-less. - Jim Filip Hanik - Dev Lists wrote: Jim Manico wrote: > I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave I think this is the best case scenario for v0 cookies. Perhaps, if you really want to get fancy, you can add a flag to let legacy solutions roll back to the old/non-standard cookie handling methodology? no, we wont do that. we fixed the cookie behavior in this release due to security issues filed against the old parsing. The security issue only exists because of a fundamentally broken servlet in the examples, and assumes the user will click on a URL. That's not what I call a security problem. Rémy - 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]
Re: Cookies are broken in 6.0.16?
Filip - you are 100% correct on this thread. Are you basically the traffic cop guarding the core of Tomcat? - Jim Mark Thomas wrote: Remy Maucherat wrote: Filip Hanik - Dev Lists wrote: Jim Manico wrote: > I guess we could throw a run time exception if the value contained any of those. other than that, I'm not sure how to behave I think this is the best case scenario for v0 cookies. Perhaps, if you really want to get fancy, you can add a flag to let legacy solutions roll back to the old/non-standard cookie handling methodology? no, we wont do that. we fixed the cookie behavior in this release due to security issues filed against the old parsing. The security issue only exists because of a fundamentally broken servlet in the examples, and assumes the user will click on a URL. That's not what I call a security problem. The root cause of the issue wasn't the servlet in the examples. If it were, that servlet would have been fixed. The issue was a number of bugs/inconsistencies in the handling of cookie headers, particularly around quoting and unquoting which enabled XSS attacks in some instances. That said the issues were all hard to exploit and required the application to use user provided data directly as the cookie value. This was why these issues were rated as low severity. An enhancement request to log when Tomcat ignores/truncates a value or identifies some other issue when parsing cookies seems reasonable to me. the thing is, the javadoc as very very clear on this, to create a v0 cookie, and put == in the end, is obviously not good :) Mark - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookies are broken in 6.0.16?
That post was meant to go to Filip only, since he is an old friend. I was not trying to poke fun at your perspective on this public list, Remy. I'm going exit stage left and stop adding my thoughts to this thread. My apologies. - Jim On Sun, 2008-02-10 at 11:44 -0500, Jim Manico wrote: Filip - you are 100% correct on this thread. Are you basically the traffic cop guarding the core of Tomcat? I understand, you are not impacted by the behavior change, and as a result this allows you to be "fair", I suppose. The issue is that the behavior of Tomcat has been different, in all prior releases, and changing it of all a sudden without any configuration capability because it feels nice to play "spec lawyer" is wrong to me. Similar decisions have been made in the past, and this did cause problems, it's simply faster to add the appropriate options right away. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DispatchData in ApplicationContext causes ClassLoader leak
Remy, I think it would serve you to review the proposed Apache code of conduct at http://wiki.apache.org/incubator/CodeOfConduct *Motto* *Core Value* * Put community before code. * * collaboration * Let they that do the work make the decisions. self-determination If it didn't happen on a mailing list, it didn't happen. transparency Merit never expires. sustained interest Critique our code, not our coders. netiquette Thank you, - Jim On Tue, 2008-03-04 at 12:32 +0200, Arto Huusko wrote: The DispatchData subclass in org.apache.cataline.core.ApplicationContext causes ClassLoader leak, when a web application is undeployed. /* And so you feel your bug is important enough to spam about it ?*/ Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding HTTPOnly support to Tomcat
Gentlemen,
I'd like to make a suggestion to add HTTPOnly support to Tomcat 5.5 (for
starters). This is a significant security enhancement that will assist
in preventing XSS attacks.
http://msdn2.microsoft.com/en-us/library/ms533046.aspx
Since the javax core is a "sacred" portion of the codebase, I'd like to
get your feedback on my solution proposal. It involves changes to the
org.apache.catalina.connector.Request.java,
org.apache.catalina.connector.Response.java and
org.apache.tomcat.util.http.ServerCookie.java.
org.apache.catalina.connector.Request.java includes the following code
to set the JSESSIONID. addCookieInternal is where the cookie magic happens.
// Creating a new session cookie based on that session
if ((session != null) && (getContext() != null)
&& getContext().getCookies()) {
Cookie cookie = new Cookie(Globals.SESSION_COOKIE_NAME,
session.getIdInternal());
configureSessionCookie(cookie);
* response.addCookieInternal(cookie);*
}
Next we would need to modify the functionality of
response.addCookieInternal in some way from
org.apache.catalina.connector.Response.java. These are my suggested
backward-compatible changes:
*public void addCookieInternal(final Cookie cookie) {
addCookieInternal(cookie, false);
**}
*
*public void addCookieInternal(final Cookie cookie, boolean HTTPOnly) {
*
if (isCommitted())
return;
final StringBuffer sb = new StringBuffer();
//web application code can receive a IllegalArgumentException
//from the appendCookieValue invokation
if (SecurityUtil.isPackageProtectionEnabled()) {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run(){
ServerCookie.appendCookieValue
(sb, cookie.getVersion(), cookie.getName(),
cookie.getValue(), cookie.getPath(),
cookie.getDomain(), cookie.getComment(),
cookie.getMaxAge(), cookie.getSecure());
return null;
}
});
} else {
ServerCookie.appendCookieValue
(sb, cookie.getVersion(), cookie.getName(),
cookie.getValue(),
cookie.getPath(), cookie.getDomain(),
cookie.getComment(),
cookie.getMaxAge(), cookie.getSecure());
}
*//of course, we really need to modify ServerCookie, but this is
the general idea
if (HTTPOnly) {
sb.append("; HttpOnly");
}
*
//if we reached here, no exception, cookie is valid
// the header name is Set-Cookie for both "old" and v.1 ( RFC2109 )
// RFC2965 is not supported by browsers and the Servlet spec
// asks for 2109.
addHeader("Set-Cookie", sb.toString());
cookies.add(cookie);
}
Any thoughts would be greatly appreciated.
- Jim
Re: Adding HTTPOnly support to Tomcat
Rely, This is not a ms hack, but a security enhancement supported by all browsers. Do some research and get back to us. Jim On Mar 10, 2008, at 5:33 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote: On Sun, 2008-03-09 at 19:56 -0700, Filip Hanik - Dev Lists wrote: haven't forgotten about you, it's still on the todo list. I am against adding support for IE only hacks ? Rémy - 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]
Re: Adding HTTPOnly support to Tomcat
Remy, I recommend more careful research on this topic. IE 6+ supports HttpOnly FireFox 2.0.0.6+ support HttpOnly Opera 9.5+ has promised HttpOnly support Safari is still considering On Mon, 2008-03-10 at 08:16 -0400, Jim Manico wrote: Rely, This is not a ms hack, but a security enhancement supported by all browsers. Do some research and get back to us. This feature does not have good browser support, and I think it's a hack. Well, at least you know how I will vote if your patch is proposed [of course, it could still go in if many people support it] :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cookie standards
According to Daniel Stenberg, Cookies are not even *mentioned* in RFC2616 Per http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0623.html "On Tue, 18 Mar 2008, Jim Manico wrote: > Are there any efforts underway to support the HttpOnly cookie directive > within any version of the HTTP Protocol? 1 - Cookies aren't included in RFC2616 at all. 2 - Hardly any implemenations of cookies follow any recent attempts to document how cookies should be handled so I doubt writing yet another cookie spec update will help much. Given the history of cookies so far, they are doomed to be adhoc'ed and work in a random undocumented fashion... (unless you count the original Netscape cookie document a specification)." Ouch. Is this true? - Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cookie standards
Right, but are there any active cookie standards that can be amended? 7 /12 year old standards are not very valid or useful in the fast-moving internut world. - Jim The standard is only 7 1/2 years old; http://www.ietf.org/rfc/rfc2965 Jim Manico wrote: According to Daniel Stenberg, Cookies are not even *mentioned* in RFC2616 Per http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0623.html "On Tue, 18 Mar 2008, Jim Manico wrote: > Are there any efforts underway to support the HttpOnly cookie directive > within any version of the HTTP Protocol? 1 - Cookies aren't included in RFC2616 at all. 2 - Hardly any implemenations of cookies follow any recent attempts to document how cookies should be handled so I doubt writing yet another cookie spec update will help much. Given the history of cookies so far, they are doomed to be adhoc'ed and work in a random undocumented fashion... (unless you count the original Netscape cookie document a specification)." Ouch. Is this true? - Jim - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat Header Injection
I'm continuing to do a security review of Tomcat 5.5 for my company. I noticed that linefeeds get ripped out of header values which stops header injection attacks cold. Whoever did this, I commend you. Many other containers do not. You Rock. Can anyone point me to the code that does this? Best, Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat Header Injection
Thank you very much, Mark and Filip. - Jim Jim Manico wrote: I'm continuing to do a security review of Tomcat 5.5 for my company. I noticed that linefeeds get ripped out of header values which stops header injection attacks cold. Whoever did this, I commend you. Many other containers do not. You Rock. InternalInputBuffer.java InternalAprInputBuffer.java InternalNioInputBuffer.java just search for parseHeaders the two first classes are similar, the third one is almost similar, except that it supports non blocking parsing of headers Filip Can anyone point me to the code that does this? Best, Jim - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
httpOnly support patches
I completed the needed patches for httpOnly support in Tomcat. Please see: https://issues.apache.org/bugzilla/show_bug.cgi?id=44382 Only 3 files were touched: org.apache.catalina.connector.Response org.apache.catalina.connector.Request and org.apache.tomcat.util.http.ServerCookie You sincere consideration would be greatly appreciated. Please at least review before you jump down my throat, Remy! :) Best, Jim Manico [EMAIL PROTECTED] Senior Application Security Engineer Aspect Security / OWASP.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HttpOnly and Kauai
Gentlemen, As a blatant bribery attempt - I live and work on the island of Kauai in Hawaii. Whomever commits this *https://issues.apache.org/bugzilla/show_bug.cgi?id=44382* Will win a free stay in my guest house. :) Food included. Zip code 96703, <5 minutes from the beach. =D -- Jim Manico Senior Application Security Engineer Aspect Security
Re: HttpOnly and Kauai
Tequila, tents, food and wireless access provided!!! Tomcat coding party at Jim's house! nice, since we work RTC (Review-Then-Commit) you're gonna have to extend this invitation to everyone who votes for the patch's inclusion :) Lol Filip Beer provided ? Jim Manico wrote: > Gentlemen, > > As a blatant bribery attempt - I live and work on the island of Kauai > in Hawaii. > > Whomever commits this > *https://issues.apache.org/bugzilla/show_bug.cgi?id=44382* > > Will win a free stay in my guest house. :) Food included. Zip code > 96703, <5 minutes from the beach. > > =D > > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.519 / Virus Database: 269.22.1/1352 - Release Date: 3/31/2008 10:13 AM > - 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] -- Jim Manico Senior Application Security Engineer Aspect Security
Re: HttpOnly and Kauai
Understood. All I am really asking/begging/patching for is a HttpOnly option for the JSESSIONID cookie. - Jim Guenter Knauf wrote: Hi, we can't do this one https://issues.apache.org/bugzilla/attachment.cgi?id=21741 that's a servlet spec class well, that wasnt clever now! You should first have commited, then made a trip to Kauai with your laptop, and then from there at the Tomcat coding party via wireless *just found* that this is invalid, told him personally, and then revoke the commit again.! LOL! I'll keep that in mind for the next time :) cheers, Guen. - 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] -- Jim Manico Senior Application Security Engineer Aspect Security - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpOnly and Kauai
> You should first have commited, then made a trip to Kauai with your laptop, and then from there at the Tomcat coding party via wireless *just found* that this is invalid, told him personally, and then revoke the commit again.! Then you could have just blamed it on the tequila! Arriba, arriba! Hi, we can't do this one https://issues.apache.org/bugzilla/attachment.cgi?id=21741 that's a servlet spec class well, that wasnt clever now! You should first have commited, then made a trip to Kauai with your laptop, and then from there at the Tomcat coding party via wireless *just found* that this is invalid, told him personally, and then revoke the commit again.! cheers, Guen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jim Manico Senior Application Security Engineer Aspect Security
Re: Web Service deployed on Tomcat stops responding after sometime
You want tomcat-users, not tomcat developers. This list is for folks who are building the Tomcat product. You will not get an answer here. - Jim Hi, I haven't used Tomcat before and is the first time I am using it. I have Web Service that is deployed on Tomcat 5 installed on my local system. Web Service I am using Spring, Hibernate. The issue I am facing is after deploying a service all works fine. As soon as I leave the service idle means I don't make any calls to the Web Service for couple of hours my Web Service stops working. If I try to invoke a Web Service I get an error message and looking at the logs I don't see any call to the Web Service so I end up undeploying and redeploying the Web Service and it starts working and if I don't invoke the Service for couple of hours it stops working and I then I have to undeploy and redeploy the Service. Any idea waht might be the problem where to look. Why the Service keeps working as long as I keep calling but stops working if I call after couple of hours. Is there any settings I need to make on Tomcat as I am new to Tomcat so have no idea where to look. Any help is appreciated. Thanks -- Jim Manico Senior Application Security Engineer Aspect Security - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Osgifing Tomcat
Remy - please consider the Apache guidelines about being respectful on the public lists. Key word: please. - Jim -Original Message- From: Remy Maucherat <[EMAIL PROTECTED]> Sent: Wednesday, April 23, 2008 7:35 AM To: Tomcat Developers List Subject: Re: Osgifing Tomcat On Tue, 2008-04-22 at 12:45 +0200, Henri Gomez wrote: > Hi to all, > > Did there is plans, ideas or interest around about OSGI-fing Tomcat ? The only thing which ever attracts you is pointless hype, it's quite funny ;) Rémy - 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]
Re: Assuring Security by testing
The Fortify Opensource project automatically scans the Tomcat codebase on a regular basis. This probably only gives you 10% security coverage at best, but it's a free report form a $50k tool. http://opensource.fortifysoftware.com Hi devs, I've been investigating Apache Tomcat within my Bachelor's thesis "Application of security test tools in open source" at the Free University of Berlin (FU Berlin) [1]. Basically, I am looking for security measures which have been taken to prevent security leaks/vulnerabilities especially with security test tools Apache Tomcat is a extremely popular servlet engine. The nature of the application offers to compromise the web apps and reveal sensitive data. It does not seem that Tomcat cannot be tested the classic way web apps are, e.g. testing with fuzzer for SQL injection, parameter tampering, path traversal etc. So far, I have search the repository and the ant build.xml, the homepage and the mailing list.The homepage and mailing list revealed no information at all to me. I did find that you refer to security audit conducted against the 5.0 codebase [2]. Unfortunately, no information was given what was found and what measures have been taken afterwards. Security advisories are taken up by a security team [3]. Does this team or any other group/person take any measures to assure security with testing tools, with a special test plan or functional requirements? Thanks in advance, Michael [1] https://www.inf.fu-berlin.de/w/SE/ThesisFOSSSecurityTools [2] http://tomcat.apache.org/tomcat-5.5-doc/security-manager-howto.html [3] http://tomcat.apache.org/security-6.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Assuring Security by testing
Mark, I agree with all of your comments 100%. If you really wanted to conduct an in-depth security analysis, the best bet is to hire a dedicated application security company to conduct a targeted code review. Most automated application security tools are crap. But for the sake of academic research, the Fortify Tomcat report might be a little interesting. -- Jim Manico, Senior Application Security Engineer [EMAIL PROTECTED] | [EMAIL PROTECTED] (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security™ Securing your applications at the source http://www.aspectsecurity.com Jim Manico wrote: The Fortify Opensource project automatically scans the Tomcat codebase on a regular basis. This probably only gives you 10% security coverage at best, but it's a free report form a $50k tool. http://opensource.fortifysoftware.com A great example of why I have don't have much faith (hope for the future yes - faith for the current crop no) in these tools. In summary: - they are looking at 4.1.10, 5.5.20 and 6.? - I don't know which TC6 version they analysed (but I suspect it is quite old) since they never responded to my requests to add me to that project and I lost interest - there are so many false positives I got fed up looking at them - the bug reporting is way to clunky compared to just using Eclipse or any other decent IDE - it missed most (all if I recall correctly - I don't have the time or inclination to check) of the XSS issues we know were in 4.1.10 onwards I maintain that you will get greater benefit for time invested just by clearing the issues flagged by a decent IDE. Mark - 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]
Re: Assuring Security by testing
> if I got you and Jim correctly, the free service provided by Coverity is almost worthless because the positive to false positive rate is awfully bad? > From your point of view this tool isn't worth 50 k$? Tool being worth 50k? I don't think so. A group a trained humans can do it much cheaper with 90% or more coverage with less false positives. But I am biased , this is what I do for a living. I think the only situation where one would use Fortify/Coverity is when I have too many apps to manually review, and I really don't care about complete appSec coverage (like I just need to pass an audit and I don't really care about security) - Jim Mark Thomas wrote: Jim Manico wrote: The Fortify Opensource project automatically scans the Tomcat codebase on a regular basis. This probably only gives you 10% security coverage at best, but it's a free report form a $50k tool. http://opensource.fortifysoftware.com A great example of why I have don't have much faith (hope for the future yes - faith for the current crop no) in these tools. In summary: - they are looking at 4.1.10, 5.5.20 and 6.? - I don't know which TC6 version they analysed (but I suspect it is quite old) since they never responded to my requests to add me to that project and I lost interest - there are so many false positives I got fed up looking at them - the bug reporting is way to clunky compared to just using Eclipse or any other decent IDE - it missed most (all if I recall correctly - I don't have the time or inclination to check) of the XSS issues we know were in 4.1.10 onwards Mark, if I got you and Jim correctly, the free service provided by Coverity is almost worthless because the positive to false positive rate is awefully bad? From your point of view this tool isn't worth 50 k$? I thought the tools are directly given to the projects. If they do not tell you what they have scanned, it's pretty superfluous to me. Thanks -- Jim Manico, Senior Application Security Engineer [EMAIL PROTECTED] | [EMAIL PROTECTED] (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security™ Securing your applications at the source http://www.aspectsecurity.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Osgifing Tomcat
> I just don't have the time. If you keep your responses to a few short paragraphs, you might get more input Filip, hey. May I ask when you think the HttpOnly patch will go live? And Mark, I've spammed you about this as well - I'm running my own custom branch eager to back back inline with the REAL Tomcat(tm). Best, Jim Peter Kriens wrote: I must admit I feel I am walking on eggs ... and I am a bit surprised how few others tune in. there is a reason few others turn in, at this point, you have written, and very well so, about 30 pages of responses. It's just to hard keep up with long essays like that, not that I don't want, I would love to, I just don't have the time. If you keep your responses to a few short paragraphs, you might get more input Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jim Manico, Senior Application Security Engineer [EMAIL PROTECTED] | [EMAIL PROTECTED] (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security™ Securing your applications at the source http://www.aspectsecurity.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
On Tomcat Concurrency Problems
A senior developer from the company I work for had the following comments (in support of Tomcat) regarding the very interesting threading post from Lloyd Chambers last week. This is an interesting post, but not for the reason that the author intended. I'm sure he's an awesome developer who totally understands this stuff. And the findings might be serious problems. But if they are real, *he blew the writeups (to the Tomcat dev list).* Reread these findings -- they're all theoretical. I guess they all sort of represent "violation of best practice". If you ever write that it just means that you can't find an actual problem to report. Every one of these findings raises obvious questions that the finding should have answered. *Always answer "who cares"* · How is SingleSignOn actually instantiated? (my guess is that there aren't lots of threads at startup). · Are the "public" get/setRequireReauthentiation() methods actually called from any different threads? (my guess is that this doesn't make a bit of difference). · Are there any classes that extend SingleSignOn? (if not then who cares about subclasses modifying non-finals). · What actually calls findSessions() and does it modify the array? (my guess is not) The conclusion that SSO is a "disaster waiting to happen" *is the kind of FUD (fear uncertainty doubt) talk that undermines the whole point.* The reference to "Java Concurrency in Practice" is probably well-intentioned, but just comes off snotty. We face these dangers in our writings (as an Application Security company) as well. Always try to put yourself in the customer's *(in this case, the Tomcat dev team) *shoes and really explain more than just the narrow-scope technical problem. If you're using the words this guy is using -- something is wrong with your findings: ·"Perhaps" ·"Could" ·"Presumably" ·"What if" ·"Bug-prone if" -- Jim Manico, Senior Application Security Engineer [EMAIL PROTECTED] | [EMAIL PROTECTED] (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security^(TM) Securing your applications at the source http://www.aspectsecurity.com (post from Lloyd Chambers) First, I'm an experienced developer, and well-versed in Java threading. My main work is on the Glassfish project at Sun. I've been looking into the code of org.apache.catalina.authenticator.SingleSignOn to see how it works, and I've noticed a number of thread-safety bugs. My understanding is that Valve SingleSignOn could run on any thread (eg any incoming request). 1. Most of the instance variables are not 'final'. So when SingleSignOn is instantiated, there is no guarantee that the instance will be seen correctly by any other thread; it's state is undefined from the point of view of another thread. Its immutable variable values (eg the Maps) should be 'final' so as to benefit from the JVM guarantee of thread safety for 'final' instance variables. And/or there needs to be an external synchronizing side-effect that would make the object instance "visible" to other threads. Perhaps there exists such an external side effect that masks this bug. 2. The get/set methods are thread-unsafe. For example, getRequireReauthentication() and setRequireReauthentication() are not 'synchronized', and the variable 'requireReauthentication' is not 'volatile'. As a result, different threads could see different values and/or never see an updated value. Since these are public methods, and presumably can be called from any number of different threads, this is a problem. 3. Variables 'lifecycle' and 'reverse' and 'cache' are not 'final'. See #1 above, but this also exposes/encourages another thread-safety issue: what if the variables themselves are changed by a subclass (since SingleSignOn is not a 'final' class). 4. The Map classes use external synchronization, which is bug-prone if any modifications are made (and there might be some race conditions here as well). The java.util.concurrent.ConcurrentHashMap class is much more scalable and doesn't have these risks. 5. Method deregister() (both variants) contain a race condition whereby the call sso.findSessions(). Method findSessions() is 'synchronized', but *returns its internal array 'sessions'*!!! Upon return there is no further thread-safety; 'sessions' is now exposed and anything looking at it is now subject to a race condition and/or "visibility" problem. These are almost certainly not all the issues. From what I can see, SingleSignOn is a disaster waiting to happen on the wrong hardware, where caches are not write-throu
RE: DO NOT REPLY [Bug 45180] New: CRLF Newline characters stripped from header values
My understanding is that crlf breaks the rfc and leads to http response
splitting attacks.
-Original Message-
From: [EMAIL PROTECTED]
Sent: Tuesday, June 10, 2008 11:50 AM
To: [EMAIL PROTECTED]
Subject: DO NOT REPLY [Bug 45180] New: CRLF Newline characters stripped from
header values
https://issues.apache.org/bugzilla/show_bug.cgi?id=45180
Summary: CRLF Newline characters stripped from header values
Product: Tomcat 5
Version: 5.5.26
Platform: PC
OS/Version: Windows Server 2003
Status: NEW
Severity: blocker
Priority: P2
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
While trying to implement RFC 2231 with "Parameter Value Continuations" I had a
header that should appear as follows:
Content-Disposition: attachment;
filename*0="Rodney.20080516.VaR_Simple.HG2008_HG2008_20080516_issueDetailLog";
filename*1="_boy_this_is_a_long_header_value";
filename*2="_now_is_it_not.csv"
That is according to RFC 2231 which allows this. I use
HttpServletResponse.addHeader(String,String) to add the appropriate header as
so:
addHeader("Content-Disposition", above value with \r\n inside the string)
Unfortanetely Tomcat is replacing my String's "\r\n" after each ";" with two
spaces instead.
This results in the actual header returned to the browser being:
Content-Disposition: attachment;
filename*0="Rodney.20080516.VaR_Simple.HG2008_HG2008_20080516_issueDetailLog";
filename*1="_boy_this_is_a_long_header_value";
filename*2="_now_is_it_not.csv"
[Each ; is followed by filename instead of
\r\nfilename]
Firefox 2.0.14 will gracefully correct this malformed, non-compliant RFC2231
header, but Internet Explorer 6 nor 7 will handle this correctly. IE is more
strict about the RFC2231 format.
I believe this may have been implemented to discourage XSS mistakes in code,
but now it breaks using \r\n inside header values.
Perhaps a new method such as "addUncheckedHeader(String,String)" that doesn't
scrub the \r\n would be appropriate?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bu
[The entire original message is not included]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JRuby sucked up the bath water but left the baby behind.
See it in Action : http://www.kewlstuff.co.za/cd_tut_swf/whatisejb1.htm --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jim Manico, Senior Application Security Engineer [EMAIL PROTECTED] | [EMAIL PROTECTED] (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security™ Securing your applications at the source http://www.aspectsecurity.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JRuby sucked up the bath water but left the baby behind.
I love this plan - a great way to turn all other languages into Java(tm) ! :) - Jim On Tue, Jun 17, 2008 at 9:22 AM, Clifton Brooks <[EMAIL PROTECTED]> wrote: If, instead of interpreting JRuby, PHP, and Jython, Tomcat, or some extensions for it, could compile programs in these languages into java servlets, then all of the advantages of the Java world will instantly become accessible to these popular languages. This suggestion is analogous to the .NET model which compiles any language into Windows only byte code. Here, any language compiles to platform independent, Java bytecode. http://jcp.org/en/jsr/detail?id=292 You just have to wait till Java 7 :-) Leon P.S. On a personal note, you simply can't build a stable reliable enterprise software with duck typed language like javascript or ruby. And running scripts in tomcat doesn't make your scripts better. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jim Manico, Senior Application Security Engineer [EMAIL PROTECTED] | [EMAIL PROTECTED] (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security™ Securing your applications at the source http://www.aspectsecurity.com
Tomcat Server Header Change
I would like to change Tomcat so that configuring the Connector to server="" will completely remove the Server header. This used to be the base before the header customization code was put in place. Does anyone have a strong objection, if not, I'll add a bug for it in bugzilla and provide a patch. -- Jim Manico, Senior Application Security Engineer [EMAIL PROTECTED] | [EMAIL PROTECTED] (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security™ Securing your applications at the source http://www.aspectsecurity.com --- Management, Developers, Security Professionals ... ... can only result in one thing. BETTER SECURITY. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: is JDK 1.1 still needed? README say Java5
I would say that the era of Java up through 1.3 is dead. Java 1.4 and above is the only thing I see in production anymore. - Jim browsing the tomcat trunk, i found org.apache.tomcat.util.collections.* is org.apache.tomcat.util.collections still used? some classes have a comment - since this package must also run on JDK 1.1 - there are some Classes wich aren't used any longer? or should not used (Enumeration replaced by Iterator) some of those (Queue) could be replaced by java.util.concurrent package i think not used/not visible are (EmptyEnumeration,MultiMapValuesEnumeration,Queue) --- Jens Kapitza - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jim Manico, Senior Application Security Engineer [EMAIL PROTECTED] | [EMAIL PROTECTED] (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security™ Securing your applications at the source http://www.aspectsecurity.com --- Management, Developers, Security Professionals ... ... can only result in one thing. BETTER SECURITY. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Exploiting Tomcat
This is a worthwhile post to read regarding path traversal attacks against tomcat. http://www.0x00.com/?i=630 -- Jim Manico, Senior Application Security Engineer [EMAIL PROTECTED] | [EMAIL PROTECTED] (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security™ Securing your applications at the source http://www.aspectsecurity.com --- Management, Developers, Security Professionals ... ... can only result in one thing. BETTER SECURITY. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exploiting Tomcat
I can feel the love. Thanks for your constructive comment, William. - Jim Jim Manico wrote: This is a worthwhile post to read regarding path traversal attacks against tomcat. http://www.0x00.com/?i=630 Worthwhile? To note the community frustration against Tomcat parsers? Must be what you meant since the author adds nothing. New information is always welcome. Primary sources for the win; http://outian.org/tomcat.pdf https://issues.apache.org/bugzilla/show_bug.cgi?id=45417 http://www.securityfocus.com/archive/1/495318/30/0/threaded - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jim Manico, Senior Application Security Engineer [EMAIL PROTECTED] | [EMAIL PROTECTED] (301) 604-4882 (work) (808) 652-3805 (cell) Aspect Security™ Securing your applications at the source http://www.aspectsecurity.com --- Management, Developers, Security Professionals ... ... can only result in one thing. BETTER SECURITY. http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference Sept 22nd-25th 2008 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: svn commit: r699015 - /tomcat/current/tc4.1.x/STATUS.txt
The books have arrived - we are all set! -Original Message- From: [EMAIL PROTECTED] Sent: Thursday, September 25, 2008 11:41 AM To: dev@tomcat.apache.org Subject: svn commit: r699015 - /tomcat/current/tc4.1.x/STATUS.txt Author: rjung Date: Thu Sep 25 09:41:36 2008 New Revision: 699015 URL: http://svn.apache.org/viewvc?rev=699015&view=rev Log: Vote. Modified: tomcat/current/tc4.1.x/STATUS.txt Modified: tomcat/current/tc4.1.x/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/current/tc4.1.x/STATUS.txt?rev=699015&r1=699014&r2=699015&view=diff == --- tomcat/current/tc4.1.x/STATUS.txt (original) +++ tomcat/current/tc4.1.x/STATUS.txt Thu Sep 25 09:41:36 2008 @@ -27,5 +27,8 @@ * Add a NOTICE file to the TC4 distribution http://people.apache.org/~markt/patches/2008-09-25-tc4-notice.patch - +1: markt + +1: markt, rjung -1: + rjung: I didn't do a detailed check on the contents of the added licenses. + But technically everything looks fine and of course there's no + new component added in this release. - 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]
Re: Findbugs results when run against Tomcat6
Findbugs does a real bad job of findings real security bugs - I would recommend running the codebase against Fortify + include the new Cigital rulepack. Or take a look at the results of the Fortify Open Source Analysis project https://opensource.fortify.com/teamserver/welcome.fhtml - Jim Just out of curiosity, I ran Findbugs 1.3.5 on Tomcat 6.0.18. The default settings generated some 1400 warnings about possible bugs. Quite a few of them look serious - assuming that the code which contains them is being used. For example, there are quite a few public static fields which are not final. There are several instances of problems with String handling, e.g. using == to compare Strings or using String.replace() without assigning the result. And there are a few instances of methods which synchronize on a field in what appears to be an attempt to guard against simultaneous updates to that field. But guarding a field gets a lock on the referenced object, not on the field. This is probably not what was intended. I can provide a listing of the analyis if required, but it might be easier to use a FindBugs IDE plugin. - 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]
RE: Findbugs results when run against Tomcat6
This is really helpful info, Mark. I'd like to get my hands on an account there, too. If all else fails try emailing [EMAIL PROTECTED] - or maybe we could getsome other vendor to donate their product and/or time -Original Message- From: Mark Thomas <[EMAIL PROTECTED]> Sent: Saturday, September 27, 2008 5:58 AM To: Tomcat Developers List Subject: Re: Findbugs results when run against Tomcat6 Jim Manico wrote: > Findbugs does a real bad job of findings real security bugs - I would > recommend running the codebase against Fortify + include the new Cigital > rulepack. > > Or take a look at the results of the Fortify Open Source Analysis project > > https://opensource.fortify.com/teamserver/welcome.fhtml Past experience with that site and it's ability to find genuine security bugs wasn't great. For example, with 4.1.10 if found a whole handful of false positives and no genuine security issues. It isn't as if there were plenty to find (http://tomcat.apache.org/security-4.html). I made some suggestions on what needed to be done to improve it over a year ago. As yet, there has been no response although it appears that some of those suggestions have been acted on which is a positive sign. Out of curiosity and I did try and request an account today to look at the latest Tomcat 6 results but the request an account link only shows the login page. I found an e-mail address so I have sent my request there. My previous conclusion was that findbugs on its own would be a better bet for finding bugs but I never got around to trying it. Sebb's e-mail has prompted me to download it and see what the results look like. Mark - 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]
URL Rewriting
URL Rewriting is consider to be a significant security risk (session ID's get exposed in browser history, bookmarks, proxy servers and other server-side application logs). I would like to propose that we create a patch for Tomcat that allows URL Rewriting to be completely disabled via configuration. Since this is a bit off the 2.5 spec, I think we might want to keep this turned on by default, with an option to disable. Several other Servlet 2.5 containers have implemented this idea some way. Anyone think this is a reasonable patch? How difficult do you think this will be, it so? Best Regards, Jim Manico - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: URL Rewriting
Great, Mark, I'll add this as a bug and take it on. - Jim > Jim Manico wrote: > >> URL Rewriting is consider to be a significant security risk (session >> ID's get exposed in browser history, bookmarks, proxy servers and other >> server-side application logs). >> >> I would like to propose that we create a patch for Tomcat that allows >> URL Rewriting to be completely disabled via configuration. Since this is >> a bit off the 2.5 spec, I think we might want to keep this turned on by >> default, with an option to disable. >> >> Several other Servlet 2.5 containers have implemented this idea some way. >> >> Anyone think this is a reasonable patch? >> > Makes sense to me. > > >> How difficult do you think this will be, it so? >> > I haven't looked in great detail but it looks like a trivial change to > o.a.c.connector.Response.toEncoded() would do the trick. Configuration > should probably be on the context to be consistent with the cookies > parameter. > > Mark > > >> Best Regards, >> Jim Manico >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: Support for httpOnly cookies in Tomcat 6.0.x
Mark, I for one an thrilled to see HTTPOnly support for Session Cookies in Tomcat 6.0 get close to fruition. My oinion is that I think that session cookies should not be tagged as HTTPOnly for Tomcat 6 by default. (Of course configuration should allow for turning this on). I worry that it's going to be rather tough to get to the bottom of what is going wrong - when extreme edge cases of HTTPOnly use causes a problem. Either way, adding HTTPOnly to Tomcat 6 will certainly go a long way is stopping session-theft based XSS attacks at the configuration level so that programmers will not need to do anything to win this protection. Sadly, Yahoo's job board was hacked with a XSS session theft attack just a few months ago - HTTPOnly would have stopped it. Best Regards to you all, (even Remy), Jim - Original Message - From: "Mark Thomas" To: "Tomcat Developers List" Sent: Wednesday, February 25, 2009 5:56 AM Subject: Re: Support for httpOnly cookies in Tomcat 6.0.x Ping. This has been hanging around the status file for a while and I'd quite like to complete it. Mark Mark Thomas wrote: Folks, The implementation of httpOnly support in Tomcat 7 fits well with the previous httpOnly patch [1] that is currently the proposed backport for 6.0.x When originally proposed there was some concern that the v3 servlet spec may require some changes. This hasn't been the case. With that in mind could folks please review their comments and votes for this patch. I'd like to get it into 6.0.19 if posible. If you still think there is room for improvement, I'm happy to take another look at this. Some pointers as to how you think things could/should be improved would be appreciated. If you do vote for this patch, please remember to indicate your preference for using or not using httpOnly for session cookies by default. Cheers, Mark [1] http://svn.apache.org/viewvc?view=rev&revision=694992 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
