Today's Tomcat 9 HTTP/2 webinar is now available on YouTube

[Mark Thomas]

All,

As promised, today's webinar "Apache Tomcat 9: HTTP/2 Quick Start" is
now available on the Apache Tomcat YouTube channel:

https://www.youtube.com/channel/UCpqpJ0-G1lYfUBQ6_36Au_g

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ServletRequest.getInputStream, getReader, getParameter.

[Christopher Schultz]

Roel,

On 11/24/15 2:19 PM, Roel Storms wrote:
> When I am in a hurry to get a website up and running and I have no
> resources to do so, security is going to be my last concern.

This item should be listed as #1 on OWASP's list of the Most Critical
Application Security Risks.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat catalina.out log is not rolling using log4j DailyRollingFileAppender

[Christopher Schultz]

Joleen,

On 11/24/15 4:31 PM, Joleen Barker wrote:
> I have setup the logrotate using cron in the past and it was very
> successful on the Linux boxes but I could not find an equivalent setup for
> AIX. Things seem so much easier on Linux. The company wants a universal
> approach so that left that option out.

Only some things are easier on Linux.

This may help:
http://www-01.ibm.com/support/docview.wss?uid=isg3T1012796

> I did see the section you copied in from the catalina.sh file but couldnt
> make much out from it so I left it alone.
> 
> I like the sound of option b. I know where the context xml file is. (Under
> the Catalina/localhost/.xml) Im not sure if this is what you mean
> by descriptor.

Yup, that's the one. Just add the swallowOutput setting and restart the
web application. (Or restart Tomcat if that's easier for you.)

> If I did this would I leave the log4j config changes that I
> have in place that already?

No, you wouldn't have to use log4j at all. JULI can do log-rotation as
well, though the options aren't as nice as log4j. Log4j is a really
great logging system, actually.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat catalina.out log is not rolling using log4j DailyRollingFileAppender

[Joleen Barker]

Thank you so much Christopher for all that information. I will look in to
the various options you've presented.

I have setup the logrotate using cron in the past and it was very
successful on the Linux boxes but I could not find an equivalent setup for
AIX. Things seem so much easier on Linux. The company wants a universal
approach so that left that option out.

I did see the section you copied in from the catalina.sh file but couldnt
make much out from it so I left it alone.

I like the sound of option b. I know where the context xml file is. (Under
the Catalina/localhost/.xml) Im not sure if this is what you mean
by descriptor. If I did this would I leave the log4j config changes that I
have in place that already?

-Joleen
On Nov 20, 2015 9:37 AM, "Christopher Schultz" 
wrote:

> Joleen,
>
> On 11/19/15 3:19 PM, Joleen Barker wrote:
> > I want to say up front that I am not a developer and know enough to brake
> > some stuff. lol
>
> Lots of "only admins" on this list. Welcome.
>
> > I have a software package from a vendor that ships the tomcat web server
> > with it. Below are my environment details:
> >
> > 1) The tomcat version that is running is v8.0.26.0
> > 2) The OS is a Centos v7 UNIX VM
> > 3) Java JDK I have installed that Tomcat is using is 1.8.0_60
> > 4) The vendor has the $CATALINA_HOME and CATALINA_BASE as the same
> location
> > which is /server
> > 5) The /server directory is the place where the /lib,
> > /bin, /conf, and etc.directory's are found.
>
> Thanks for providing all that information up front.
>
> > 6) Due to the catalina.out file growing too large with the default
> > juli.AsyncFileHandler using the logging.properties file that was found in
> > the $CATALINA_HOME/conf directory. I changed it to use the log4j logging.
> > Here are the steps I did to make this happen which I found on Tomcat 8
> web
> > site:
> >
> >   a. Downloaded log4j-1.2.17.jar and placed it in
> $CATALINA_HOME/lib
> >   b. Downloaded from the Tomcat extras web page for Tomcat 8 the
> > tomcat-juli-adapters.jar and the tomcat-juli.jar.
> >   c. Deleted the old tomcat-juli.jar out of the
> $CATALINA_HOME/bin
> > directory.
> >   d. Placed the new tomcat-juli.jar file and the
> > tomcat-juli-adapters.jar file in to the $CATALINA_HOME/bin directory.
> >   e. Deleted the old logging.properties file from the
> > $CATALINA_HOME/conf directory.
> >f. Created the log4j.properties file in the $CATALINA_HOME/lib
> > directory and copied the settings that are shown on the Tomcat 8 logging
> > web page that has been there for Tomcat 7 logging web page too that
> > everyone is familiar with. Here is the url just incase:
> > https://tomcat.apache.org/tomcat-8.0-doc/logging.html
> >
> > I know the log4j.properties files is being used as I made 2 changes to
> the
> > config file that were taken. One changes was to actually verify the
> > log4j.properties file was being used, which was changed the word INFO to
> > OFF for localhost file messages being written by editing the following
> line
> > at the bottom of the log4j.properties file:
> >
> >
> log4j.logger.org.apache.catalina,core.ConainerBase.[Catalina].[localhost] =
> > OFF, LOCALHOST
> >
> > The other change I made was I changed the file name in the following line
> > to read catalina.out instead of catalina:
> > log4j.appender,CATALINA.File = ${catalina.base}/logs/catalina.out
> >
> > The reason I did this was I thought the daily roll that was supposed to
> > take place at midnight would occur on the file that was named catalina
> and
> > not on the file that was named catalina.out. All the INFO messages being
> > written to the file named catalina were also being written to the
> > catalina.out file which was the one I wanted to roll daily anyway so I
> > thought this change would be fine.
> >
> > I stopped tomcat and cleared all the logs out and left the server to run
> > over night. (It is still running now) and it appears the roll did not
> take
> > place. What I woke up to was everything you see below found in the
> > $CATALINA_HOME/logs directory except for the one file written today which
> > was due to me logging in to the web application that the vendor supports
> so
> > I could verify I could still login and use the software:
> >
> > -rw-r--r--.  root  root  33003 Nov 18 21:03 catalina.out
> > -rw-r--r--.  root  root 0 Nov 18 21:03 host-manager
> > -rw-r--r--.  root  root 0 Nov 18 21:03 localhost
> > -rw-r--r--.  root  root 0 Nov 18 21:03
> > localhost_access_log.2015-11-18.txt
> > -rw-r--r--.  root  root2498 Nov 19 13:23
> > localhost_access_log.2015-11-19.txt
> > -rw-r--r--.  root  root 0 Nov 18 21:03 manager
> >
> > I don't know what I am missing from the configs to make the catalina.out
> > file roll each day at midnight. Some help would be greatly appreciated.
>
> You did a great investigation and (nearly) all the steps you took were
> 

TLS fails in Firefox and Chrome

[Mark Robinson]

I'm having this problem with TLS in Firefox and Chrome.  Some of my
requests are failing with an SSL MAC Bad Read error.  I'm using Tomcat
8.0.24 on Java 8.0_u66 / Ubuntu 14.04.  So it works fine with IE, and
if I disable some ciphers then it works.

If I disable these ciphers TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, then it works just fine.

I've tried installing the Unlimited policy file.

Has anyone else experienced this?  Is there a known problem with these ciphers?

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ServletRequest.getInputStream, getReader, getParameter.

[Christopher Schultz]

Roel,

On 11/24/15 10:43 AM, Roel Storms wrote:
> 2015-11-24 16:11 GMT+01:00 Christopher Schultz > :
> 
>> Roel,
>>
>> On 11/24/15 9:44 AM, Roel Storms wrote:
>>> I am trying to protect the client from:
>>>
>>> Session fixation
>>
>> Tomcat already provides session-fixation protection when using URL-based
>> or cookie-based session-tracking. When authentication occurs, Tomcat
>> will change the session identifier, effectively mitigating session
>> fixation.
>>
>> I'm not saying that Tomcat is vulnerable if used correctly. I am saying
> that
> naive implementations using cookie based session management can be
> vulnerable. Tomcat and other middleware  will indeed try to cover up
> these security issues. We want to change the basic shortcoming that an SID
> acts as a bearer token.

But you are saying that you want to replace bearer tokens (defined by
you as intractable) with a new kind of bearer token. I don't see you
having much luck without a lot of infrastructure. Since one of your
initial requirements was "minimal infrastructure", your proposal is
current indistinguishable from magic.

>>> Session hijacking
>>
>> I'm interested in your plan for this that (a) is transparent to the
>> application, (b) is easy to implement on the server and (c) does not
>> require any changes to the client.
>>
> I have changed the client. I have a working implementation in Chrome
> that does everything except for body integrity checking. TLS also
> need both client and server side implementations. Cookies also have
> to be supported at the client side.

So, this is something that the application doesn't have to know about,
but every other component in the works DOES need to have it? The list of
conflicting requirements here is really amusing to me.

>>> Maybe I also want to check integrity of the response since otherwise an
>>> active MitM attack can still modify this.
>>
>> If you have solved the client -> server integrity, then server -> client
>> integrity ought to be trivial.
>>
> 
> True, but I'm not sure I want to cover active MitM. If you want to protect
> against that you should use TLS. I'm simply trying to replace the
> fundamental insecurity of SID.

If you can change both client and server, then simply negotiate a secret
(during your "safe" session-establishment step, which you have asserted
but not described) and sign everything in both directions. Problem solved.

>>> An attack could consists of an attacker modifying the action
>>> attribute of a form to send login data to the attacker instead of the
>>> web application.
>>
>> A reasonable attack scenario, especially with the attacker has a MitM
>> position.
>>
>>> But this again looks a lot like TLS with DH_anon.
>>
>> It does? Or do you mean even if TLS is used with anon-auth (i.e. ZERO
>> auth), the client isn't protected from MitM?
> 
> 
> Doing integrity checking on both request and response and doing this
> integrity check for almost the entire HTTP request/response looks
> a lot like TLS.

It sure does. If you only protect a part of the payload, what's stopping
the rest of the payload from attacking the "safe" part? E.g. fingerprint
the first 1k of the HTML document, but the attacker injects javascript
at the end which goes-in and re-writes the DOM. Partial protection is
zero protection.

>>> Al we want is to replace the current session mechanism
>>> where the ID is a bearer token by a mechanism based on a shared secret
>>> (shared via DH).
>>
>> How is this different from "standard" TLS-sessions (formal TLS sessions,
>> not Tomcat's session ids in cookies transmitted via TLS)?
> 
> 
> The difference is that TLS assures integrity of the entire packet. Which is
> not compatible with web infrastructure. Also TLS is often not deployed.
> Or even if it is deployed there is still mixed content being server.
> Our sessions would be applicable to both types of content.
> 
>  "To our knowledge, SecSess is the only session management
>  mechanism explicitly designed to be compatible with currently
>  deployed Web infrastructure, such as web caches."
> https://lirias.kuleuven.be/bitstream/123456789/503824/1/p2171-de_ryck.pdf
> 
> I haven't validated this claim but my thesis builds upon this paper.

Now I know why this was all sounding *really* familiar. I've ready this
paper and -- maybe I'm just not smart enough but -- it seems like a lot
of fanciful thinking without solving a real problem. It uses real
problems to invent straw men that it then solves with a dubious
solution. This idea is a SELL, not a BUY.

>>> This will inhibit script based attacks that steal the SID
>>> and also eavesdropping attacks. It's not perfect but we also believe that
>>> if you have an active MitM, you have bigger problems than securing your
>>> session management.
>>
>> Of course. That doesn't make it an interesting scenario, though.
>>
>>> The perfect solution is still something including SSL/TLS (it's not
>>> cookie based since even over SSL cookies 

Re: TLS fails in Firefox and Chrome

[Christopher Schultz]

Mark,

On 11/24/15 12:36 PM, Mark Robinson wrote:
> I'm having this problem with TLS in Firefox and Chrome.  Some of my
> requests are failing with an SSL MAC Bad Read error.  I'm using Tomcat
> 8.0.24 on Java 8.0_u66 / Ubuntu 14.04.  So it works fine with IE, and
> if I disable some ciphers then it works.
> 
> If I disable these ciphers TLS_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, then it works just fine.
> 
> I've tried installing the Unlimited policy file.
> 
> Has anyone else experienced this?  Is there a known problem with these 
> ciphers?

When your config isn't working, what does your  configuration
look like? Remember to sanitize the config to remove any secrets.

Also, are you using any related system properties to control JSSE, etc.?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: TLS fails in Firefox and Chrome

[Mark Robinson]

My config is pretty vanilla.



This fails, because of the three problematic ciphers.

 As far as I know I'm not using any system properties to control JSSE.

On Tue, Nov 24, 2015 at 10:16 AM, Christopher Schultz
 wrote:
> Mark,
>
> On 11/24/15 12:36 PM, Mark Robinson wrote:
>> I'm having this problem with TLS in Firefox and Chrome.  Some of my
>> requests are failing with an SSL MAC Bad Read error.  I'm using Tomcat
>> 8.0.24 on Java 8.0_u66 / Ubuntu 14.04.  So it works fine with IE, and
>> if I disable some ciphers then it works.
>>
>> If I disable these ciphers TLS_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, then it works just fine.
>>
>> I've tried installing the Unlimited policy file.
>>
>> Has anyone else experienced this?  Is there a known problem with these 
>> ciphers?
>
> When your config isn't working, what does your  configuration
> look like? Remember to sanitize the config to remove any secrets.
>
> Also, are you using any related system properties to control JSSE, etc.?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ServletRequest.getInputStream, getReader, getParameter.

[Roel Storms]

The only way cookie based session management is secure, is when
you apply a number of countermeasures:

Correct flags, path and domain attributes, no un-trusted applications
on subdomains (solved by origin cookies), ...
You run it over TLS to withstand sniffers.
There is no clean mechanism to share a session between domains.
Again people have invented solutions.
OWASP had quite some information on the subject:
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

Session management in Tomcat is secure because the developpers of
tomcat have applied (almost) all of these countermeasures but not
everyone is using middleware like Tomcat.
If as you say there is no problem with session management, then why
was 'Broken Authentication and Session Management' second on the
list of the 10 Most Critical Web Application Security Risks according to
OWASP?
This is what SecSess is doing for you:
http://randomoverload.org/wp-content/uploads/2015/09/2e36hF7158F31.jpg

When I am in a hurry to get a website up and running and I have no
resources to do so, security is going to be my last concern. If we can
create a session management mechanism which outperforms current
session management out of the box and allow an application developer
to pick this option without any modification to his source code I think
we could reduce the problem big time.

I'm not claiming they aren't solved. I am claiming there is not
A SOLUTION, but merely patches on an insecure mechanism.
In theory everything should just run over TLS but for some reason that
is not the case and for some reason there are still major problems with
authentication and session management. I think we should look at the
number of available solutions and try to improve it.

I am not going to argue about something which clearly doesn't belong
on this mailing list anymore. But I disagree with you on the fact that
session management is fine the way it is.

Thanks for the advice and I clearly have some technical stuff to work out.

Roel

2015-11-24 19:15 GMT+01:00 Christopher Schultz :

> Roel,
>
> On 11/24/15 10:43 AM, Roel Storms wrote:
> > 2015-11-24 16:11 GMT+01:00 Christopher Schultz <
> ch...@christopherschultz.net
> >> :
> >
> >> Roel,
> >>
> >> On 11/24/15 9:44 AM, Roel Storms wrote:
> >>> I am trying to protect the client from:
> >>>
> >>> Session fixation
> >>
> >> Tomcat already provides session-fixation protection when using URL-based
> >> or cookie-based session-tracking. When authentication occurs, Tomcat
> >> will change the session identifier, effectively mitigating session
> >> fixation.
> >>
> >> I'm not saying that Tomcat is vulnerable if used correctly. I am saying
> > that
> > naive implementations using cookie based session management can be
> > vulnerable. Tomcat and other middleware  will indeed try to cover up
> > these security issues. We want to change the basic shortcoming that an
> SID
> > acts as a bearer token.
>
> But you are saying that you want to replace bearer tokens (defined by
> you as intractable) with a new kind of bearer token. I don't see you
> having much luck without a lot of infrastructure. Since one of your
> initial requirements was "minimal infrastructure", your proposal is
> current indistinguishable from magic.
>
> >>> Session hijacking
> >>
> >> I'm interested in your plan for this that (a) is transparent to the
> >> application, (b) is easy to implement on the server and (c) does not
> >> require any changes to the client.
> >>
> > I have changed the client. I have a working implementation in Chrome
> > that does everything except for body integrity checking. TLS also
> > need both client and server side implementations. Cookies also have
> > to be supported at the client side.
>
> So, this is something that the application doesn't have to know about,
> but every other component in the works DOES need to have it? The list of
> conflicting requirements here is really amusing to me.
>
> >>> Maybe I also want to check integrity of the response since otherwise an
> >>> active MitM attack can still modify this.
> >>
> >> If you have solved the client -> server integrity, then server -> client
> >> integrity ought to be trivial.
> >>
> >
> > True, but I'm not sure I want to cover active MitM. If you want to
> protect
> > against that you should use TLS. I'm simply trying to replace the
> > fundamental insecurity of SID.
>
> If you can change both client and server, then simply negotiate a secret
> (during your "safe" session-establishment step, which you have asserted
> but not described) and sign everything in both directions. Problem solved.
>
> >>> An attack could consists of an attacker modifying the action
> >>> attribute of a form to send login data to the attacker instead of the
> >>> web application.
> >>
> >> A reasonable attack scenario, especially with the attacker has a MitM
> >> position.
> >>
> >>> But this again looks a lot like TLS with DH_anon.
> >>
> >> It does? Or do you 

Re: ServletRequest.getInputStream, getReader, getParameter.

[Mark Thomas]

On 24/11/2015 10:12, Roel Storms wrote:
> It's to implement a new session mechanism that guarantees integrity of the
> requests sent in the session and also protect the session from attacks
> based on stealing or replacing the session identifier. This is a thesis I'm
> working on and this Tomcat valve should prove that migration from cookie
> base session management to this new session management can go without large
> modifications at client and server-side. That's why it is important to make
> it transparent to the user/developer. Performance is already going to be an
> issue in multiple places but I'll see what I can come up with.
> 
> I am weighing of transparency, ease of migration, performance and security
> all the time. Checking at the Apache httpd level will make it harder to
> migrate to this new session management mechanism and has some other
> disadvantages. In theory i could do this session management in a proxy but
> this has it's own disadvantages. Session scope is an important aspect in
> it's security and scope is harder to get right in a proxy or in the httpd
> server since I want to limit scope to the web application context and maybe
> allow explicit session sharing between web applications. As you can see I
> still have a lot to do. If I need any more information I will not hesitate
> to ask. Thanks for all the info!

What does this get you over and above using TLS (which is rapidly
becoming a given due to HTTP/2) and configuring Tomcat to use the TLS
session ID as the HTTP session identifier?

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ServletRequest.getInputStream, getReader, getParameter.

[Roel Storms]

It's to implement a new session mechanism that guarantees integrity of the
requests sent in the session and also protect the session from attacks
based on stealing or replacing the session identifier. This is a thesis I'm
working on and this Tomcat valve should prove that migration from cookie
base session management to this new session management can go without large
modifications at client and server-side. That's why it is important to make
it transparent to the user/developer. Performance is already going to be an
issue in multiple places but I'll see what I can come up with.

I am weighing of transparency, ease of migration, performance and security
all the time. Checking at the Apache httpd level will make it harder to
migrate to this new session management mechanism and has some other
disadvantages. In theory i could do this session management in a proxy but
this has it's own disadvantages. Session scope is an important aspect in
it's security and scope is harder to get right in a proxy or in the httpd
server since I want to limit scope to the web application context and maybe
allow explicit session sharing between web applications. As you can see I
still have a lot to do. If I need any more information I will not hesitate
to ask. Thanks for all the info!

2015-11-23 23:01 GMT+01:00 André Warnier (tomcat) :

> On 23.11.2015 21:14, Roel Storms wrote:
>
>> Ok, thank you for the clear response. I see the problem with file type
>> elements.
>>
>
> If you really have an overwhelming need to pre-check whole POST bodies
> before passing them to a Tomcat application, you may want to think about
> fronting your Tomcat server with an Apache httpd server.  You could then do
> the checking at the Apache httpd level, before forwarding the request to
> Tomcat. And of course not forward it at all if the check fails.
> Doing this at the front-end level would not "consume" the request body, as
> it does when you do this under Tomcat.
> All in all, you would still end up reading the request body twice.  But
> depending on your use case, it may be worth it.
>
> In your initial post below, you wrote "..some integrity checking on HTTP
> requests (the details aren't important)..".
> But if you want further help or recommendations, I believe that more
> details about what exactly you are trying to achieve and/or check, would be
> important.
> After all, Tomcat is already making a fair amount of checking by default,
> on any received HTTP request, before it will forward it to any
> application.  So it would be interesting to have an idea of which extra
> checks you want to make.
>
>
>
>
>> 2015-11-23 17:18 GMT+01:00 André Warnier (tomcat) :
>>
>> On 23.11.2015 16:31, Mark Thomas wrote:
>>>
>>> On 23/11/2015 14:30, Roel Storms wrote:

 Hello,
>
> I am working on a Valve that does some integrity checking on HTTP
> requests
> (the details aren't important) where I need this valve to have access
> to
> the HTTP request body as well. I used request.getInputStream to fetch
> the
> data. However when a web application makes use of my valve, the
> getParameter method does not return the parameters submitted via POST
> anymore. This is documented behavior according to the spec of
> ServletRequest (
>
>
> https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream()
> ).
>
> I was wondering why it was designed this way,
>
>
 Given the potential size of a request body, streaming is the only viable
 option.

 since numerous complaints

> have arisen from this behavior and some ugly workarounds have been
> devised
> which unfortunately stop working from Tomcat 7 (servlet 3.0):
>
>
>
> https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once
>
> This shows how easily code like this could break.
>
>
 What that shows is the folks haven't thought through what they are
 trying to do. Consider the following:

 Tomcat provides request R.
 Filter reads request body using R.getInputStream().
 Filter caches request body.
 Filter wraps request R to provide R', over-riding getInputStream() to
 provide the cached body.
 Filter passes R' to the application.
 Application calls R'.getParameter()
 R'.getParameter() calls R.getParameter()

 Keep in mind at this point R has zero knowledge of R'.

 R calls getInputStream() to read request body but that InputStream has
 already been read.

 The problem is the wrapper, R'. Over-riding getInputStream() is not
 enough. It needs to over-ride every method that may access that
 InputStream. Which is non-trivial because it means re-implementing a lot
 of functionality the container would normally provide for you out of the
 box.

 Overwriting 

Re: ServletRequest.getInputStream, getReader, getParameter.

[Christopher Schultz]

André,

On 11/23/15 11:18 AM, André Warnier (tomcat) wrote:
> On 23.11.2015 16:31, Mark Thomas wrote:
>> On 23/11/2015 14:30, Roel Storms wrote:
>>> Hello,
>>>
>>> I am working on a Valve that does some integrity checking on HTTP
>>> requests
>>> (the details aren't important) where I need this valve to have access to
>>> the HTTP request body as well. I used request.getInputStream to fetch
>>> the
>>> data. However when a web application makes use of my valve, the
>>> getParameter method does not return the parameters submitted via POST
>>> anymore. This is documented behavior according to the spec of
>>> ServletRequest (
>>> https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html#getInputStream()
>>>
>>> ).
>>>
>>> I was wondering why it was designed this way,
>>
>> Given the potential size of a request body, streaming is the only viable
>> option.
>>
>>> since numerous complaints
>>> have arisen from this behavior and some ugly workarounds have been
>>> devised
>>> which unfortunately stop working from Tomcat 7 (servlet 3.0):
>>>
>>> https://stackoverflow.com/questions/10210645/http-servlet-request-lose-params-from-post-body-after-read-it-once
>>>
>>>
>>> This shows how easily code like this could break.
>>
>> What that shows is the folks haven't thought through what they are
>> trying to do. Consider the following:
>>
>> Tomcat provides request R.
>> Filter reads request body using R.getInputStream().
>> Filter caches request body.
>> Filter wraps request R to provide R', over-riding getInputStream() to
>> provide the cached body.
>> Filter passes R' to the application.
>> Application calls R'.getParameter()
>> R'.getParameter() calls R.getParameter()
>>
>> Keep in mind at this point R has zero knowledge of R'.
>>
>> R calls getInputStream() to read request body but that InputStream has
>> already been read.
>>
>> The problem is the wrapper, R'. Over-riding getInputStream() is not
>> enough. It needs to over-ride every method that may access that
>> InputStream. Which is non-trivial because it means re-implementing a lot
>> of functionality the container would normally provide for you out of the
>> box.
>>
>>> Overwriting getInputStream to return a cached version doesn't work
>>> anymore
>>
>> Nope. That never worked. See my explanation above.
>>
>>> since the parameter attribute isn't populated by using
>>> getInputStream. How
>>> exactly it is populated remains a mystery to me. Any advice on how to
>>> solve
>>> this properly?
>>
>> Write a better wrapper.
>>
>>> Performing an integrity check without getInputStream or getReader but
>>> with
>>> getParameters, will not work if the data submitted is not in the
>>> expected
>>> format.
>>
>> See above.
>>
>> Mark
>>
> 
> To emphasize a point made by Mark above : a POST body can potentially
> contain one or more  elements.  So imagine a POST
> which contains a 50 MB uploaded file.
> You'd need to read it once (for your Valve) and cache it, then re-read
> the cached version to parse it for parameters.  That would have a
> serious impact on performance.
> (That's what Mark means by "streaming..").
> And because it is a Valve, it would run before the request has been
> mapped to any application, so the hit would be for all applications in
> the server.

Valves can be placed in a number of different locations. I believe all
Valves will fire after the host and application have been mapped, but
all Valves will certainly fire before any application code (e.g.
Filters) will fire.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ServletRequest.getInputStream, getReader, getParameter.

[Roel Storms]

TLS will sign everything and therefor will not allow fine-grained integrity
checking. Why do we want this? Middleboxes might alter some non-security
sensitive information and I don't want to drop those requests. But I am
looking into TLS already to see if I can use it for my purpose. We
certainly don't want the full encryption or authentication that TLS can
offer. No encryption since we don't want to interfere with caching and no
authentication since setting up the certificates is often one of the
reasons for small web apps not to use TLS. You have to get your certificate
from an authority, keep it safe, install it and pay for it. We notice that
adoption of TLS is not as great as we'd like it to be for securing cookie
based session management so we need an alternative that will be adopted
more easily and guarantee security of sessions better than plain cookie
based session management. As a thesis it is an interesting subject to study
although it's quite probable that the people too busy to use TLS will also
be too busy to use our session management mechanism.

Using TLS without certificates is only possible with the DH_Anon
cyphersuite which is often disabled by clients and server.

" The server MUST send a Certificate message whenever the agreed-

  upon key exchange method uses certificates for authentication
  (this includes all key exchange methods defined in this document
  except DH_anon)." RFC 5246 (TLS 1.2)


" The following cipher suites are used for completely anonymous

   Diffie-Hellman communications in which neither party is
   authenticated.  Note that this mode is vulnerable to man-in-the-
   middle attacks.  Using this mode therefore is of limited use: These
   cipher suites MUST NOT be used by TLS 1.2 implementations unless the
   application layer has specifically requested to allow anonymous key
   exchange." RFC 5246


Also we want to support mixed content web apps without having the risk of
being vulnerable to session hijacking. Some of these properties can be
obtained by using SSL session identifier in Tomcat as your session
mechanism. Again, I am still doing some research and maybe what I am doing
is not worth it.

2015-11-24 11:36 GMT+01:00 Mark Thomas :

> On 24/11/2015 10:12, Roel Storms wrote:
> > It's to implement a new session mechanism that guarantees integrity of
> the
> > requests sent in the session and also protect the session from attacks
> > based on stealing or replacing the session identifier. This is a thesis
> I'm
> > working on and this Tomcat valve should prove that migration from cookie
> > base session management to this new session management can go without
> large
> > modifications at client and server-side. That's why it is important to
> make
> > it transparent to the user/developer. Performance is already going to be
> an
> > issue in multiple places but I'll see what I can come up with.
> >
> > I am weighing of transparency, ease of migration, performance and
> security
> > all the time. Checking at the Apache httpd level will make it harder to
> > migrate to this new session management mechanism and has some other
> > disadvantages. In theory i could do this session management in a proxy
> but
> > this has it's own disadvantages. Session scope is an important aspect in
> > it's security and scope is harder to get right in a proxy or in the httpd
> > server since I want to limit scope to the web application context and
> maybe
> > allow explicit session sharing between web applications. As you can see I
> > still have a lot to do. If I need any more information I will not
> hesitate
> > to ask. Thanks for all the info!
>
> What does this get you over and above using TLS (which is rapidly
> becoming a given due to HTTP/2) and configuring Tomcat to use the TLS
> session ID as the HTTP session identifier?
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: ServletRequest.getInputStream, getReader, getParameter.

[Christopher Schultz]

Roel,

On 11/24/15 5:12 AM, Roel Storms wrote:
> It's to implement a new session mechanism that guarantees integrity of the
> requests sent in the session and also protect the session from attacks
> based on stealing or replacing the session identifier. This is a thesis I'm
> working on and this Tomcat valve should prove that migration from cookie
> base session management to this new session management can go without large
> modifications at client and server-side. That's why it is important to make
> it transparent to the user/developer. Performance is already going to be an
> issue in multiple places but I'll see what I can come up with.
> 
> I am weighing of transparency, ease of migration, performance and security
> all the time. Checking at the Apache httpd level will make it harder to
> migrate to this new session management mechanism and has some other
> disadvantages. In theory i could do this session management in a proxy but
> this has it's own disadvantages. Session scope is an important aspect in
> it's security and scope is harder to get right in a proxy or in the httpd
> server since I want to limit scope to the web application context and maybe
> allow explicit session sharing between web applications. As you can see I
> still have a lot to do. If I need any more information I will not hesitate
> to ask. Thanks for all the info!

Are you trying to protect the client and server from an evil proxy, or
are you trying to protect the server from an evil client?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ServletRequest.getInputStream, getReader, getParameter.

[Christopher Schultz]

Roel,

On 11/24/15 9:17 AM, Roel Storms wrote:
> TLS will sign everything and therefor will not allow fine-grained integrity
> checking. Why do we want this? Middleboxes might alter some non-security
> sensitive information and I don't want to drop those requests. But I am
> looking into TLS already to see if I can use it for my purpose. We
> certainly don't want the full encryption or authentication that TLS can
> offer. No encryption since we don't want to interfere with caching and no
> authentication since setting up the certificates is often one of the
> reasons for small web apps not to use TLS.

So, you want to support caching and don't want to deal with authentication.

If you don't care about authentication, why do you care about integrity?

> You have to get your certificate
> from an authority, keep it safe, install it and pay for it.

That's pretty easy. It's possible to get free certificates [1] [2].
Let's Encrypt is even making it all automated.

> We notice that adoption of TLS is not as great as we'd like it to be
> for securing cookie based session management so we need an
> alternative that will be adopted more easily and guarantee security
> of sessions better than plain cookie based session management.

TLS + cookies is the only workable solution for the foreseeable future.
To support anything else, you'd have to have code running on both the
client and the server (or, alternatively, get a change made to one or
more specifications to force clients to implement your strategy).

> As a thesis it is an interesting subject to study although it's quite
> probable that the people too busy to use TLS will also be too busy to
> use our session management mechanism.

If you know what you are doing, you can set up a TLS server from scratch
in about 5 minutes. The problem is that most people don't understand
X.509 and just Google for "how to configure SSL" and type-in whatever
commands happen to be there.

> Using TLS without certificates is only possible with the DH_Anon
> cyphersuite which is often disabled by clients and server.

The use of encryption without (cert) authentication is certainly an
interesting use-case. I think the only reason it's usually disabled is
because browsers don't have a really good way to say to a user "this
channel is encrypted, but we can't prove AT ALL who is on the other end.
so your transaction is secure to the extent that nobody ELSE is
observing it, but ... the party at the other end might not be
trustworthy, so it's all moot".

> Also we want to support mixed content web apps without having the risk of
> being vulnerable to session hijacking. Some of these properties can be
> obtained by using SSL session identifier in Tomcat as your session
> mechanism. Again, I am still doing some research and maybe what I am doing
> is not worth it.

Session-hijacking is pretty much always a possibility when the client is
providing its own identification to the server: the only defense is to
use SSL sessions (meaning, SSL-session as the authentication mechanism)
or to try your best not to ever disclose the session cookie's value over
a cleartext channel.

-chris

[1] https://www.startssl.com/
[2] https://letsencrypt.org/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ServletRequest.getInputStream, getReader, getParameter.

[Roel Storms]

I am trying to protect the client from:

Session fixation
Session hijacking
Assure that requests that are received in an established session can't be
modified in transit (integrity of requests).
Maybe I also want to check integrity of the response since otherwise an
active MitM attack can still modify this. An attack could consists of an
attacker modifying the action attribute of a form to send login data to the
attacker instead of the web application. But this again looks a lot like
TLS with DH_anon. Al we want is to replace the current session mechanism
where the ID is a bearer token by a mechanism based on a shared secret
(shared via DH). This will inhibit script based attacks that steal the SID
and also eavesdropping attacks. It's not perfect but we also believe that
if you have an active MitM, you have bigger problems than securing your
session management. The perfect solution is still something including
SSL/TLS (it's not cookie based since even over SSL cookies can be leaked if
not set properly and we don't want a configuration mistake to become a
security issue).

I am not trying to protect from:

An active MitM attack during session establishment
Malware at either client or server-side


2015-11-24 15:19 GMT+01:00 Christopher Schultz :

> Roel,
>
> On 11/24/15 5:12 AM, Roel Storms wrote:
> > It's to implement a new session mechanism that guarantees integrity of
> the
> > requests sent in the session and also protect the session from attacks
> > based on stealing or replacing the session identifier. This is a thesis
> I'm
> > working on and this Tomcat valve should prove that migration from cookie
> > base session management to this new session management can go without
> large
> > modifications at client and server-side. That's why it is important to
> make
> > it transparent to the user/developer. Performance is already going to be
> an
> > issue in multiple places but I'll see what I can come up with.
> >
> > I am weighing of transparency, ease of migration, performance and
> security
> > all the time. Checking at the Apache httpd level will make it harder to
> > migrate to this new session management mechanism and has some other
> > disadvantages. In theory i could do this session management in a proxy
> but
> > this has it's own disadvantages. Session scope is an important aspect in
> > it's security and scope is harder to get right in a proxy or in the httpd
> > server since I want to limit scope to the web application context and
> maybe
> > allow explicit session sharing between web applications. As you can see I
> > still have a lot to do. If I need any more information I will not
> hesitate
> > to ask. Thanks for all the info!
>
> Are you trying to protect the client and server from an evil proxy, or
> are you trying to protect the server from an evil client?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: ServletRequest.getInputStream, getReader, getParameter.

[Christopher Schultz]

Roel,

On 11/24/15 9:44 AM, Roel Storms wrote:
> I am trying to protect the client from:
> 
> Session fixation

Tomcat already provides session-fixation protection when using URL-based
or cookie-based session-tracking. When authentication occurs, Tomcat
will change the session identifier, effectively mitigating session fixation.

> Session hijacking

I'm interested in your plan for this that (a) is transparent to the
application, (b) is easy to implement on the server and (c) does not
require any changes to the client.

> Assure that requests that are received in an established session can't be
> modified in transit (integrity of requests).

Without TLS or trusted code running on the client, I don't see a viable
solution.

> Maybe I also want to check integrity of the response since otherwise an
> active MitM attack can still modify this.

If you have solved the client -> server integrity, then server -> client
integrity ought to be trivial.

> An attack could consists of an attacker modifying the action
> attribute of a form to send login data to the attacker instead of the
> web application.

A reasonable attack scenario, especially with the attacker has a MitM
position.

> But this again looks a lot like TLS with DH_anon.

It does? Or do you mean even if TLS is used with anon-auth (i.e. ZERO
auth), the client isn't protected from MitM?

> Al we want is to replace the current session mechanism
> where the ID is a bearer token by a mechanism based on a shared secret
> (shared via DH).

How is this different from "standard" TLS-sessions (formal TLS sessions,
not Tomcat's session ids in cookies transmitted via TLS)?

> This will inhibit script based attacks that steal the SID
> and also eavesdropping attacks. It's not perfect but we also believe that
> if you have an active MitM, you have bigger problems than securing your
> session management.

Of course. That doesn't make it an interesting scenario, though.

> The perfect solution is still something including SSL/TLS (it's not 
> cookie based since even over SSL cookies can be leaked if not set
> properly and we don't want a configuration mistake to become a
> security issue).

Configuration mistakes can always result in vulnerabilities. The only
way to fail-safe would be to disallow all "unsafe" configurations, which
would make the software *quite* unusable.

> I am not trying to protect from:
> 
> An active MitM attack during session establishment
> Malware at either client or server-side

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Fwd:

[Christopher Schultz]

Yuval,

On 11/23/15 8:38 AM, Yuval Schwartz wrote:
> I am using tomcat 8.0.22.0
> Language: Java
> development: Windows, NetBeans.
> deployment: ec2 linux
> 
> I am still having trouble understanding/working with "path" and "docBase"
> of context element.
>
> I have two questions:
> 
> First of all, I have a context.xml file in the WEB-INF folder of my
> application (call it "myApplication" henceforth) that looks like:
> 
> 

You should never specify the "path" attribute in your context.xml file.
Instead, name the WAR file (or exploded directory) the same name as you
want your context's path to be. For a path of "" (empty), use the name
ROOT.war (or ROOT directory).

>  maxActive="100" maxIdle="30" maxWait="1"
> username="blah" password="blahblah"
> driverClassName="com.mysql.jdbc.Driver"
> url="jdbc:mysql://localhost:3306/some_db?autoReconnect=true"
> logAbandoned="true" removeAbandoned="true"
> removeAbandonedTimeout="60" type="javax.sql.DataSource" />
> 
> 
> My context path is set to the empty string because once I set up a domain
> name it will be redundant to have both the application name and domain name
> in the url (they are the same).

See above.

> This works on my development environment.

You may notice that your application is deployed on both context paths,
taking up twice as much heap space. Or it might not. Using "path" within
a context.xml file not well-defined, but it is expressly prohibited in
the documentation[1] though not actively prohibited by code.

> When I deploy this to a linux server of an ec2 instance (on aws) I add a
> line to the server.xml file (in tomcat/conf) under the  element which
> reads:
> 

You should not do this. Instead, drop your ROOT.war into Tomcat's
deployment directory. If you move to EBS, you'll just be deploying the
WAR file anyway and shouldn't touch the application servers at all.

> (If I don't add this element to the server.xml file then entering just the
> domain in the url takes me to the Apache Tomcat "successful installation"
> page rather than to the welcome page of myApplication).

Use ROOT.war.

> First question:
> Is this the correct way to set up tomcat so that my application has no
> context path?

No. Note that it /does/ have a context path: it's just an empty string.

> Not sure if this leads to the "double deployment" problem or
> not. When I open the tomcat manager I see two applications: one with path:
> "/" and the other with path "/myApplication". (for some reason, I don't
> have the option to "undeploy" the application with path: "/")

You don't have that option because you have put your  into
server.xml.

> Second question:
> The resource element within the context element of my context.xml file
> (located in WEB-INF) specifies a url that is specific to my development (ie
> local) environment.

Which URL? The JDBC URL?

> When I deploy myApplication to the ec2 instance I would like the resource
> element to have a different url attribute (since it will now be connecting
> with a database on an aws server).
> One way that I found to do this was to add to the context.xml file in the
> tomcat/conf directory of my server.

Nonnononoon. Never modify the conf/context.xml file... that changes the
defaults for every application deployed. While you may be deploying only
a single application, it then separates your configuration into two
files when one single file will do.

> There I add a resource element (between
> the existing context element) which is identical to the one above only with
> a url attribute that points to the database hosted on aws.

Package your WAR file with the correct URL and then deploy it.

> This way, my application is able to connect with my database without me
> changing any of the code in myApplication.
> However, my Catalina.log file displays:
> WARNING [localhost-startStop-1]
> org.apache.catalina.core.NamingContextListener.add Resource Failed to
> register in JMX: javax.naming.NamingException: Could not create resource
> factory instance [Root exception is java.lang.ClassNotFoundException:
> org.apache.tomcat.dbcp.dbcp2.BasicDataSourceFactory]
> 
> And my localhost.log file shows a nullpointerexception for the line in my
> code:
> ic.lookup("java:comp/env/jdbc/some_db");
> (Where ic is an InitialContext Object)
> 
> There are also problems in the deployed website with some of the code that
> grabs data from the db (but some of the db related code works successfully).
> 
> Any insight or suggestions would be greatly appreciated.
> I'm new to a lot of this (extremely new to deploying to a server).

This second issue is discussed in another part of this thread.

-chris

[1]
http://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Defining_a_context

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Fwd:

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Subject: Re: Fwd:

> > First of all, I have a context.xml file in the WEB-INF folder of my
> > application (call it "myApplication" henceforth) that looks like:

Also note that WEB-INF is not the correct directory for context.xml.  The OP 
really, really needs to read the documentation:
http://tomcat.apache.org/tomcat-8.0-doc/config/context.html

The OP also needs to learn to use a subject line - he has a history of failing 
to do so.

 - Chuck


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ServletRequest.getInputStream, getReader, getParameter.

[Roel Storms]

2015-11-24 16:11 GMT+01:00 Christopher Schultz :

> Roel,
>
> On 11/24/15 9:44 AM, Roel Storms wrote:
> > I am trying to protect the client from:
> >
> > Session fixation
>
> Tomcat already provides session-fixation protection when using URL-based
> or cookie-based session-tracking. When authentication occurs, Tomcat
> will change the session identifier, effectively mitigating session
> fixation.
>
> I'm not saying that Tomcat is vulnerable if used correctly. I am saying
that
naive implementations using cookie based session management can be
vulnerable. Tomcat and other middleware  will indeed try to cover up
these security issues. We want to change the basic shortcoming that an SID
acts as a bearer token. There has been academic papers criticizing this
bearer token pattern.
https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final162.pdf



> > Session hijacking
>
> I'm interested in your plan for this that (a) is transparent to the
> application, (b) is easy to implement on the server and (c) does not
> require any changes to the client.
>
> I have changed the client. I have a working implementation in Chrome
that does everything except for body integrity checking. TLS also
need both client and server side implementations. Cookies also have
to be supported at the client side.


> > Assure that requests that are received in an established session can't be
> > modified in transit (integrity of requests).
>
> Without TLS or trusted code running on the client, I don't see a viable
> solution.
>
See above.

>
> > Maybe I also want to check integrity of the response since otherwise an
> > active MitM attack can still modify this.
>
> If you have solved the client -> server integrity, then server -> client
> integrity ought to be trivial.
>

True, but I'm not sure I want to cover active MitM. If you want to protect
against that you should use TLS. I'm simply trying to replace the
fundamental
insecurity of SID.

>
> > An attack could consists of an attacker modifying the action
> > attribute of a form to send login data to the attacker instead of the
> > web application.
>
> A reasonable attack scenario, especially with the attacker has a MitM
> position.
>
> > But this again looks a lot like TLS with DH_anon.
>
> It does? Or do you mean even if TLS is used with anon-auth (i.e. ZERO
> auth), the client isn't protected from MitM?


Doing integrity checking on both request and response and doing this
integrity check for almost the entire HTTP request/response looks
a lot like TLS.

>


> > Al we want is to replace the current session mechanism
> > where the ID is a bearer token by a mechanism based on a shared secret
> > (shared via DH).
>
> How is this different from "standard" TLS-sessions (formal TLS sessions,
> not Tomcat's session ids in cookies transmitted via TLS)?


The difference is that TLS assures integrity of the entire packet. Which is
not compatible with web infrastructure. Also TLS is often not deployed.
Or even if it is deployed there is still mixed content being server.
Our sessions would be applicable to both types of content.

 "To our knowledge, SecSess is the only session management
 mechanism explicitly designed to be compatible with currently
 deployed Web infrastructure, such as web caches."
https://lirias.kuleuven.be/bitstream/123456789/503824/1/p2171-de_ryck.pdf

I haven't validated this claim but my thesis builds upon this paper.

>


> > This will inhibit script based attacks that steal the SID
> > and also eavesdropping attacks. It's not perfect but we also believe that
> > if you have an active MitM, you have bigger problems than securing your
> > session management.
>
> Of course. That doesn't make it an interesting scenario, though.
>
> > The perfect solution is still something including SSL/TLS (it's not
> > cookie based since even over SSL cookies can be leaked if not set
> > properly and we don't want a configuration mistake to become a
> > security issue).
>
> Configuration mistakes can always result in vulnerabilities. The only
> way to fail-safe would be to disallow all "unsafe" configurations, which
> would make the software *quite* unusable.
>
Some configurations which are possible for cookies or tricks which are
possible with url-rewriting aren't possible with a session management
mechanism that was explicitly designed as a session management
mechanism. Now the middleware is trying to shield this underlying complexity
from application developers but it doesn't make the complexity disappear.
Someone still takes care of it. In this case Tomcat does. We want a
session mechanism that shield every middleware developper from these
security issues. Cookies weren't designed with security in mind. Neither
is the workaround we call url-rewriting. It's as if people kept patching t
he existing solutions without realizing that the fundamental bearer token
property model should be replaced.

I know it sounds like an attack on Tomcat but I