Re: Host header validation

[Katya Todorova <ka...@gmail.com>]

>
> Applied. Many thanks.
>
> If you'd like to work on this further then can I suggest you take a look
> at Konstantin's comments:
>
> http://markmail.org/message/vp5voob7elspflax


I looked at the comments and it seems there are things to be clarified
before going in this direction:
- should we introduce a flag for turn on/off validation and in which cases
- zone id support in IPv6 addresses
- IPvFuture support (for this one Konstantin has already proposed to be
postponed for a while)
If you think this is the right time to work on the first two, let me know
and I can prepare a patch.


Other possibilities are:
>
> - performance improvements for the Host header validation
>
> - improving code coverage generally for any of the HTTP parsing code
>
> - any that attracts your interest


I'm looking at the code coverage and will take a look at host validation
performance.

Kind regards,
Katya

Re: Host header validation

[Mark Thomas <ma...@apache.org>]

On 10/04/17 07:42, Katya Todorova wrote:
> On Wed, Apr 5, 2017 at 3:57 PM, Mark Thomas <ma...@apache.org> wrote:
> 
>> On 05/04/2017 07:50, Katya Todorova wrote:
>>
>>>
>>>> Applied. Many thanks.
>>>>
>>>> If you'd like to work on this further then can I suggest you take a look
>>>> at Konstantin's comments:
>>>>
>>>> http://markmail.org/message/vp5voob7elspflax
>>>>
>>>
>>>
>>> I looked at the comments and it seems there are things to be clarified
>>> before going in this direction:
>>> - should we introduce a flag for turn on/off validation and in which cases
>>>
>>
>> Currently, the validation isn't used at the point where the header is
>> parsed.
>>
>> I'd prefer not to add an option to disable this check. It just seems like
>> the wrong thing to do.
>>
>> I'm currently thinking that we could add the validation and log failures
>> (rather than return a 400 response) warning that a future release will
>> start rejecting the requests. That should prompt users to contact us with
>> any false positives.
> 
> 
> I think logging failure instead of returning 400 at that point is a good
> approach. How much time do you think would be enough to simply log before
> enforcing these checks? (asking out of curiosity) Also, would it be
> possible to have this functionality in tomcat 7/8?

Probably 3 to 6 months. A lot will depend on the volume of the false
positive reports we get and whether or not this identifies any broken
clients that are sending invalid host headers.

My guess is that back-porting to 8.5.x is likely whereas back-porting to
7.0.x might happen depending on what we see with 9.0.x and 8.5.x.

>> - zone id support in IPv6 addresses
>>>
>>
>> - IPvFuture support (for this one Konstantin has already proposed to be
>>> postponed for a while)
>>>
>>
>> Looking at the spec, I think we can parse IPvFuture now. We should
>> probably log any IPvFuture values with a request to report the use case to
>> us so we can update the parser to handle specific instances rather tan the
>> general case.
>>
>> If you think this is the right time to work on the first two, let me know
>>> and I can prepare a patch.
>>>
>>
>> I think that would be great. BUT. That isn't my decision to make. One of
>> the key principles of the Apache Way is that contributors choose what they
>> want to work on. There isn't a project leader or a management team
>> assigning tasks. If you want to work on this then absolutely, go ahead. If
>> there is some other aspect you'd rather be working on then by all means
>> work on that.
>>
>> The Tomcat community is always willing to provide some pointers to
>> suitable tasks where people new to Tomcat can get started but that
>> shouldn't be see as assigning areas to work on.
> 
> 
> Thank you for clarifying the process. I decided to look at these things
> because they are related to what I've already done and would, in a way,
> complete the effort around host parsing. I was asking about IPvFuture in
> particular because it seems the specification will evolve and host parsing
> code would need to be adapted accordingly, probably incrementally. While
> the rest of the host definition seems pretty stable and in use.
> That said, I'm not interested in particular in IPvFuture implementation - I
> thought it would help me getting to know Tomcat better  - if there's
> anything else that is more important/urgent and is suitable for someone new
> to Tomcat, please share some pointers. I don't see this as task assignment
> but more as providing the context/priority information that I currently
> lack.

Great. I just wanted to make sure you - and any other potential
contributors - didn't get the wrong impression.

Kind regards,

Mark


> 
> Kind regards,
> Katya
> 
> Other possibilities are:
>>>
>>>>
>>>> - performance improvements for the Host header validation
>>>>
>>>> - improving code coverage generally for any of the HTTP parsing code
>>>>
>>>> - any that attracts your interest
>>>>
>>>
>>>
>>> I'm looking at the code coverage and will take a look at host validation
>>> performance.
>>>
>>
>> Fantastic. (With the caveat of you'd rather do something else then that
>> would be fantastic too.)
>>
>>
>> Kind regards,
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

Re: Host header validation

[Katya Todorova <ka...@gmail.com>]

On Wed, Apr 5, 2017 at 3:57 PM, Mark Thomas <ma...@apache.org> wrote:

> On 05/04/2017 07:50, Katya Todorova wrote:
>
>>
>>> Applied. Many thanks.
>>>
>>> If you'd like to work on this further then can I suggest you take a look
>>> at Konstantin's comments:
>>>
>>> http://markmail.org/message/vp5voob7elspflax
>>>
>>
>>
>> I looked at the comments and it seems there are things to be clarified
>> before going in this direction:
>> - should we introduce a flag for turn on/off validation and in which cases
>>
>
> Currently, the validation isn't used at the point where the header is
> parsed.
>
> I'd prefer not to add an option to disable this check. It just seems like
> the wrong thing to do.
>
> I'm currently thinking that we could add the validation and log failures
> (rather than return a 400 response) warning that a future release will
> start rejecting the requests. That should prompt users to contact us with
> any false positives.


I think logging failure instead of returning 400 at that point is a good
approach. How much time do you think would be enough to simply log before
enforcing these checks? (asking out of curiosity) Also, would it be
possible to have this functionality in tomcat 7/8?


> - zone id support in IPv6 addresses
>>
>
> - IPvFuture support (for this one Konstantin has already proposed to be
>> postponed for a while)
>>
>
> Looking at the spec, I think we can parse IPvFuture now. We should
> probably log any IPvFuture values with a request to report the use case to
> us so we can update the parser to handle specific instances rather tan the
> general case.
>
> If you think this is the right time to work on the first two, let me know
>> and I can prepare a patch.
>>
>
> I think that would be great. BUT. That isn't my decision to make. One of
> the key principles of the Apache Way is that contributors choose what they
> want to work on. There isn't a project leader or a management team
> assigning tasks. If you want to work on this then absolutely, go ahead. If
> there is some other aspect you'd rather be working on then by all means
> work on that.
>
> The Tomcat community is always willing to provide some pointers to
> suitable tasks where people new to Tomcat can get started but that
> shouldn't be see as assigning areas to work on.


Thank you for clarifying the process. I decided to look at these things
because they are related to what I've already done and would, in a way,
complete the effort around host parsing. I was asking about IPvFuture in
particular because it seems the specification will evolve and host parsing
code would need to be adapted accordingly, probably incrementally. While
the rest of the host definition seems pretty stable and in use.
That said, I'm not interested in particular in IPvFuture implementation - I
thought it would help me getting to know Tomcat better  - if there's
anything else that is more important/urgent and is suitable for someone new
to Tomcat, please share some pointers. I don't see this as task assignment
but more as providing the context/priority information that I currently
lack.

Kind regards,
Katya

Other possibilities are:
>>
>>>
>>> - performance improvements for the Host header validation
>>>
>>> - improving code coverage generally for any of the HTTP parsing code
>>>
>>> - any that attracts your interest
>>>
>>
>>
>> I'm looking at the code coverage and will take a look at host validation
>> performance.
>>
>
> Fantastic. (With the caveat of you'd rather do something else then that
> would be fantastic too.)
>
>
> Kind regards,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Re: Host header validation

[Mark Thomas <ma...@apache.org>]

On 05/04/2017 07:50, Katya Todorova wrote:
>>
>> Applied. Many thanks.
>>
>> If you'd like to work on this further then can I suggest you take a look
>> at Konstantin's comments:
>>
>> http://markmail.org/message/vp5voob7elspflax
>
>
> I looked at the comments and it seems there are things to be clarified
> before going in this direction:
> - should we introduce a flag for turn on/off validation and in which cases

Currently, the validation isn't used at the point where the header is 
parsed.

I'd prefer not to add an option to disable this check. It just seems 
like the wrong thing to do.

I'm currently thinking that we could add the validation and log failures 
(rather than return a 400 response) warning that a future release will 
start rejecting the requests. That should prompt users to contact us 
with any false positives.

> - zone id support in IPv6 addresses

> - IPvFuture support (for this one Konstantin has already proposed to be
> postponed for a while)

Looking at the spec, I think we can parse IPvFuture now. We should 
probably log any IPvFuture values with a request to report the use case 
to us so we can update the parser to handle specific instances rather 
tan the general case.

> If you think this is the right time to work on the first two, let me know
> and I can prepare a patch.

I think that would be great. BUT. That isn't my decision to make. One of 
the key principles of the Apache Way is that contributors choose what 
they want to work on. There isn't a project leader or a management team 
assigning tasks. If you want to work on this then absolutely, go ahead. 
If there is some other aspect you'd rather be working on then by all 
means work on that.

The Tomcat community is always willing to provide some pointers to 
suitable tasks where people new to Tomcat can get started but that 
shouldn't be see as assigning areas to work on.

> Other possibilities are:
>>
>> - performance improvements for the Host header validation
>>
>> - improving code coverage generally for any of the HTTP parsing code
>>
>> - any that attracts your interest
>
>
> I'm looking at the code coverage and will take a look at host validation
> performance.

Fantastic. (With the caveat of you'd rather do something else then that 
would be fantastic too.)

Kind regards,

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org