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: 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: 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: 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 

Re: ServletRequest.getInputStream, getReader, getParameter.

[Roel Storms]

Ok, thank you for the clear response. I see the problem with file type
elements.

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 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.
>
> (Of course, in some authentication scenarios, this already happens behind
> the scenes.  But you can avoid it by designing the application accordingly.
> See : https://tomcat.apache.org/tomcat-8.0-doc/config/http.html -->
> Common Attributes --> maxSavePostSize)
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

ServletRequest.getInputStream, getReader, getParameter.

[Roel Storms]

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, 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.

Overwriting getInputStream to return a cached version doesn't work anymore
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?

Performing an integrity check without getInputStream or getReader but with
getParameters, will not work if the data submitted is not in the expected
format.

Kind regards,

Roel Storms

Re: ServletRequest.getInputStream, getReader, getParameter.

[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 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.

(Of course, in some authentication scenarios, this already happens behind
the scenes.  But you can avoid it by designing the application accordingly.
See : https://tomcat.apache.org/tomcat-8.0-doc/config/http.html -->
Common Attributes --> maxSavePostSize)




-
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.

[Mark Thomas]

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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: ServletRequest.getInputStream, getReader, getParameter.

[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 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.


(Of course, in some authentication scenarios, this already happens behind the scenes.  But 
you can avoid it by designing the application accordingly.
See : https://tomcat.apache.org/tomcat-8.0-doc/config/http.html --> Common Attributes --> 
maxSavePostSize)




-
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-23 16:31 GMT+01:00 Mark Thomas :

> 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.
>
> A better wrapper would need to implement every method using the stream. To
get a correct output from parseParameters it doesn't suffice to override
readPostBody and readChunkedPostBody since these are overridden in the
wrapper but the implementation of parseParameter in the Request won't use
them. Overriding parseParameters as well, can't be done since it uses a lot
of protected flags (parametersParsed, usingInputStream, usingReader,...).
This would mean overriding almost the entire Request. Every time you need a
protected attribute or operation in your overriding implementation, you
need to override this attribute and operation as well. In the end you would
copy almost the entire request.

> 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 unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>