Re: New module mod_allowhandlers / Controlling script execution

[Jeff Trawick]

On Tuesday, November 6, 2012, Stefan Fritsch wrote:

> Hi,
>
> On Sat, 21 Apr 2012, Jeff Trawick wrote:
>
>> there is the problem that if modules like mod_status or
>>> mod_proxy_balancer are loaded, all people with permissions to create
>>> .httaccess files can use the status pages by using SetHandler in an
>>> .htaccess file.
>>>
>>
>> My 2 cents:
>>
>> SetHandler shouldn't be used to enable these because it requires an
>> unnecessary filesystem walk and only requires a very small amount of
>> code to implement a flag directive.  Having ServerStatus On|Off
>> anywhere in the configuration would disable the check for r->handler
>> == "status-handler" (migration).
>>
>
> I must admit that I haven't looked into why they use the handler for
> configuration. But my feeling is that we won't get rid of modules doing it
> this in the forseeable future.
>
>  Is the use of handler by these a feature though, such as needing to
>> let other modules generate these reports by some mechanism other than
>> using a subrequest for or redirecting to the location where it is
>> enabled?  I don't know how smooth mod_allowhandler would be for that
>> anyway.
>>
>
> It does the checks at the end of the fixup hook, which seems to work with
> the setups I could think of. But more testing is needed, of course.
>
>  There are other situations where mod_allowhandlers would be helpful,
>> but I think we could provide a simpler mechanism (flag) for the
>> several sensitive handlers in bundled modules.
>>
>
> I think having it in trunk would be nice to find problems with this
> approach. Unless someone disagrees, I am going to commit it. Backport to
> 2.4 can wait until we are sure that it is a good solution.


+1


>
> Cheers,
> Stefan
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Rethinking "be liberal in what you accept"

[Stefan Fritsch]

Hi,

considering the current state of web security, the old principle of "be 
liberal in what you accept" seems increasingly inadequate for web servers. 
It causes lots of issues like response splitting, header injection, cross 
site scripting, etc. The book "Tangled Web" by Michal Zalewski is a good 
read on this topic, the chapter on HTTP is available for free download at 
http://nostarch.com/tangledweb .


Also, nowadays performance bottle necks are usually in other places than 
request parsing. A few more cycles spent for additional checks won't make 
much difference. Therefore, I think it would make sense to integrate some 
sanity checks right into the httpd core. For a start, these would need to 
be enabled in the configuration.


Examples for such checks [RFC 2616 sections in brackets]:

Request line:
- Don't interpret all kinds of junk as "HTTP/1.0" (like "HTTP/ab" or
  "FOO") [3.1]
- If a method is not registered, bail out early.
  This would prevent CGIs from answering requests to strange methods like
  "HELO" or "http://foo/bar";. This must be configurable or there must be
  at least a directive to easily register custom methods.  Otherwise, at
  least forbid strange characters in the method. [The method is a token,
  which should not contain control characters and separators; 2.2, 5.1]
- Forbid control characters in URL
- Forbid fragment parts in the URL (i.e. "#..." which should never be sent
  by the browser)
- Forbid special characters in the scheme part of absoluteURL requests,
  e.g. "<>"

Request headers:
- In Host header, only allow reasonable characters, i.e. no control
  characters, no "<>&". Maybe: only allow ascii letters, digits, and
  "-_.:[]"
- Maybe replace the Host header with the request's hostname, if they are
  different. In:
GET http://foo/ HTTP/1.1
Host: bar
  The "Host: bar" MUST be ignored by RFC 2616 [5.2]. As many webapps likely
  don't do that, we could replace the Host header to avoid any confusion.
- Don't accept requests with multiple Content-Length headers. [4.2]
- Don't accept control characters in header values (in particular single CRs,
  which we don't treat specially, but other proxies may. [4.2]

Response headers:
- Maybe error out if an output header value or name contains CR/LF/NUL (or
  all control characters?) [4.2]
- Check that some headers appear only once, e.g. Content-Length.
- Potentially check in some headers (e.g. Content-Disposition) that key=value
  pairs appear only once (this may go too far / or be too expensive).

Other:
- Maybe forbid control characters in username + password (after base64
  decoding)

As a related issue, it should be possible to disable HTTP 0.9.

The dividing line to modules like mod_security should be that we only 
check things that are forbidden by some standard and that we only look at 
the protocol and not the body.  Also, I would only allow to switch the 
checks on and off, no further configurability. And the checks should be 
implemented efficiently, i.e. don't parse things several times to do the 
checks, normally don't use regexes, etc.


What do you think?

Cheers,
Stefan

Re: Rethinking "be liberal in what you accept"

[Nick Kew]

On Wed, 7 Nov 2012 12:26:23 +0100 (CET)
Stefan Fritsch  wrote:


> What do you think?

I've made occasional efforts in this direction in the past,
but never seen much interest in bringing such functionality
into core (as opposed to WAF).

One such: http://people.apache.org/~niq/mod_taint.html

-- 
Nick Kew

Re: Rethinking "be liberal in what you accept"

[Jim Jagielski]

Certainly once mod_lua is more "production ready", we could
use that, couldn't we?

On Nov 7, 2012, at 6:54 AM, Nick Kew  wrote:

> On Wed, 7 Nov 2012 12:26:23 +0100 (CET)
> Stefan Fritsch  wrote:
> 
> 
>> What do you think?
> 
> I've made occasional efforts in this direction in the past,
> but never seen much interest in bringing such functionality
> into core (as opposed to WAF).
> 
> One such: http://people.apache.org/~niq/mod_taint.html
> 
> -- 
> Nick Kew
> 

Re: Rethinking "be liberal in what you accept"

[Stefan Fritsch]

On Wed, 7 Nov 2012, Nick Kew wrote:

What do you think?


I've made occasional efforts in this direction in the past,
but never seen much interest in bringing such functionality
into core (as opposed to WAF).

One such: http://people.apache.org/~niq/mod_taint.html


What you proposed there was broader in scope, using regular expressions 
allowing lots of flexibility and allowing it to be adjusted to your 
webapps. I really only want to interpret the RFCs more strictly, and do 
that fast.


Looking at mod_taint, I think it may be useful for 2.2. But in 2.4, quite 
a bit of it can be done with :



  Require all denied

Re: Rethinking "be liberal in what you accept"

[Stefan Fritsch]

On Wed, 7 Nov 2012, Jim Jagielski wrote:


Certainly once mod_lua is more "production ready", we could
use that, couldn't we?


One could of course. But not everyone has lua, lua is slower than C, and 
even doing it in a module instead of core is sometimes more work. For 
example, currently we set r->protocol to "HTTP/1.0" even if the original 
request contained junk. So a module would have to re-parse the whole 
request line to get the protocol string sent by the client.


My goal is something that the vast majority of people would want to 
activate, and would create pressure on manufacturers of clients that 
cannot cope with it to fix their clients.

Re: Rethinking "be liberal in what you accept"

[Graham Leggett]

On 07 Nov 2012, at 3:34 PM, Stefan Fritsch  wrote:

> One could of course. But not everyone has lua, lua is slower than C, and even 
> doing it in a module instead of core is sometimes more work. For example, 
> currently we set r->protocol to "HTTP/1.0" even if the original request 
> contained junk. So a module would have to re-parse the whole request line to 
> get the protocol string sent by the client.
> 
> My goal is something that the vast majority of people would want to activate, 
> and would create pressure on manufacturers of clients that cannot cope with 
> it to fix their clients.

+1.

Perhaps a "strict mode" that defaults to off in 2.4, and on in 2.5+?

Regards,
Graham
--



smime.p7s
Description: S/MIME cryptographic signature

Re: Rethinking "be liberal in what you accept"

[Stefan Fritsch]

On Wed, 7 Nov 2012, Graham Leggett wrote:

On 07 Nov 2012, at 3:34 PM, Stefan Fritsch  wrote:


One could of course. But not everyone has lua, lua is slower than C, and even doing it in a 
module instead of core is sometimes more work. For example, currently we set r->protocol 
to "HTTP/1.0" even if the original request contained junk. So a module would have 
to re-parse the whole request line to get the protocol string sent by the client.

My goal is something that the vast majority of people would want to activate, 
and would create pressure on manufacturers of clients that cannot cope with it 
to fix their clients.


+1.

Perhaps a "strict mode" that defaults to off in 2.4, and on in 2.5+?


Exactly.

Re: Rethinking "be liberal in what you accept"

[Jim Jagielski]

On Nov 7, 2012, at 8:34 AM, Stefan Fritsch  wrote:

> On Wed, 7 Nov 2012, Jim Jagielski wrote:
> 
>> Certainly once mod_lua is more "production ready", we could
>> use that, couldn't we?
> 
> One could of course. But not everyone has lua, lua is slower than C, and even 
> doing it in a module instead of core is sometimes more work.

My response was in regards to mod_taint...

Re: Rethinking "be liberal in what you accept"

[Stefan Fritsch]

On Wed, 7 Nov 2012, Jim Jagielski wrote:

One could of course. But not everyone has lua, lua is slower than C, and even 
doing it in a module instead of core is sometimes more work.


My response was in regards to mod_taint...


Sorry, then I misunderstood.

Cheers,
Stefan

Re: svn commit: r1406719 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number include/http_core.h server/core.c server/protocol.c

[Graham Leggett]

On 7 Nov 2012, at 17:56, s...@apache.org wrote:

> Author: sf
> Date: Wed Nov  7 16:56:38 2012
> New Revision: 1406719
> 
> URL: http://svn.apache.org/viewvc?rev=1406719&view=rev
> Log:
> New directive HttpProtocol which allows to disable HTTP/0.9 support.

It feels wrong targeting 0.9 only, would it be possible to do this in a generic 
way, say by listing the ones accepted, or by specifying a minimum?

Regards,
Graham
--

Re: svn commit: r1406719 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number include/http_core.h server/core.c server/protocol.c

[Jim Jagielski]

On Nov 7, 2012, at 12:05 PM, Graham Leggett  wrote:

> On 7 Nov 2012, at 17:56, s...@apache.org wrote:
> 
>> Author: sf
>> Date: Wed Nov  7 16:56:38 2012
>> New Revision: 1406719
>> 
>> URL: http://svn.apache.org/viewvc?rev=1406719&view=rev
>> Log:
>> New directive HttpProtocol which allows to disable HTTP/0.9 support.
> 
> It feels wrong targeting 0.9 only, would it be possible to do this in a 
> generic way, say by listing the ones accepted, or by specifying a minimum?
> 

Almost seems like using Limit would even be better... :/

Re: Rethinking "be liberal in what you accept"

[Ben Laurie]

On Wed, Nov 7, 2012 at 1:34 PM, Stefan Fritsch  wrote:
> On Wed, 7 Nov 2012, Jim Jagielski wrote:
>
>> Certainly once mod_lua is more "production ready", we could
>> use that, couldn't we?
>
>
> One could of course. But not everyone has lua, lua is slower than C, and
> even doing it in a module instead of core is sometimes more work. For
> example, currently we set r->protocol to "HTTP/1.0" even if the original
> request contained junk. So a module would have to re-parse the whole request
> line to get the protocol string sent by the client.
>
> My goal is something that the vast majority of people would want to
> activate, and would create pressure on manufacturers of clients that cannot
> cope with it to fix their clients.

+1.

Good luck with getting clients fixed, tho :-)

Re: svn commit: r1406719 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number include/http_core.h server/core.c server/protocol.c

[Stefan Fritsch]

On Wed, 7 Nov 2012, Graham Leggett wrote:


On 7 Nov 2012, at 17:56, s...@apache.org wrote:


Author: sf
Date: Wed Nov  7 16:56:38 2012
New Revision: 1406719

URL: http://svn.apache.org/viewvc?rev=1406719&view=rev
Log:
New directive HttpProtocol which allows to disable HTTP/0.9 support.


It feels wrong targeting 0.9 only, would it be possible to do this in a generic 
way, say by listing the ones accepted, or by specifying a minimum?


Any suggestions for a syntax? Maybe:

HttpProtocol 1.1# only 1.1
HttpProtocol 1.0-   # 1.0 and above
HttpProtocol 1.0-1.1# 1.0 and 1.1
HttpProtocol -1.0   # 1.0 and below

We could then still add additional flags like +/- strict.

Re: Rethinking "be liberal in what you accept"

[Tim Bannister]

On 7 Nov 2012, at 11:26, Stefan Fritsch wrote:

> considering the current state of web security, the old principle of "be 
> liberal in what you accept" seems increasingly inadequate for web servers. It 
> causes lots of issues like response splitting, header injection, cross site 
> scripting, etc. The book "Tangled Web" by Michal Zalewski is a good read on 
> this topic, the chapter on HTTP is available for free download at 
> http://nostarch.com/tangledweb .

> If a method is not registered, bail out early.


Good idea, but it would be nice to be able to use  or  to 
re-allow it.

-- 
Tim Bannister – is...@jellybaby.net



smime.p7s
Description: S/MIME cryptographic signature

Re: svn commit: r1406719 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number include/http_core.h server/core.c server/protocol.c

[Graham Leggett]

On 07 Nov 2012, at 8:12 PM, Stefan Fritsch  wrote:

> Any suggestions for a syntax? Maybe:
> 
> HttpProtocol 1.1  # only 1.1
> HttpProtocol 1.0- # 1.0 and above
> HttpProtocol 1.0-1.1  # 1.0 and 1.1
> HttpProtocol -1.0 # 1.0 and below
> 
> We could then still add additional flags like +/- strict.

The "-" in front of something means "switch this off" in other directives, I 
suspect it might cause confusion.

Would it make sense to try use globbing (apr_fnmatch)? Perhaps multiple options 
separated by commas, or an ITERATE separated by spaces?

HttpProtocol *  # any version
HttpProtocol 1.1# only 1.1
HttpProtocol 1.*# 1.0 and above
HttpProtocol 1.0,1.1# 1.0 and 1.1
HttpProtocol 0.*,1.0# 1.0 and below

RFC2616 defines the version as follows:

   HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

We could potentially also add a check to make sure that "DIGIT" part is checked 
to be actual digits, and reject it otherwise.

Regards,
Graham
--



smime.p7s
Description: S/MIME cryptographic signature

Re: svn commit: r1406719 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number include/http_core.h server/core.c server/protocol.c

[Tim Bannister]

On 7 Nov 2012, at 18:12, Stefan Fritsch wrote:
> On Wed, 7 Nov 2012, Graham Leggett wrote:
> 
>>> New directive HttpProtocol which allows to disable HTTP/0.9 support.
>> 
>> It feels wrong targeting 0.9 only, would it be possible to do this in a 
>> generic way, say by listing the ones accepted, or by specifying a minimum?
> 
> Any suggestions for a syntax? Maybe:
> 
> HttpProtocol 1.1  # only 1.1
> HttpProtocol 1.0- # 1.0 and above
> HttpProtocol 1.0-1.1  # 1.0 and 1.1
> HttpProtocol -1.0 # 1.0 and below

Does it need its own directive? How about a new environment variable and 
Require:

Require expr %{HTTP_PROTOCOL} -gt 1.1


I realise that won't work as things stand, because -gt only handles integers. 
Maybe another binary operator could allow decimals?

NB. SERVER_PROTOCOL would not be suitable because the initial “HTTP/” makes it 
harder to do math.

-- 
Tim Bannister – is...@jellybaby.net



smime.p7s
Description: S/MIME cryptographic signature

Re: svn commit: r1406719 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number include/http_core.h server/core.c server/protocol.c

[André Malo]

* Graham Leggett wrote:

> On 7 Nov 2012, at 17:56, s...@apache.org wrote:
> > Author: sf
> > Date: Wed Nov  7 16:56:38 2012
> > New Revision: 1406719
> >
> > URL: http://svn.apache.org/viewvc?rev=1406719&view=rev
> > Log:
> > New directive HttpProtocol which allows to disable HTTP/0.9 support.
>
> It feels wrong targeting 0.9 only, would it be possible to do this in a
> generic way, say by listing the ones accepted, or by specifying a
> minimum?

Hmm, what would be the use case? I see it with HTTP/0.9, but I don't see it 
with >= HTTP/1.0. I'd prefer kind of "duck typing" for those, like 
asking "is a valid host header present?" - which is already possible.

nd
-- 
"Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3)"
  -- aus einer Rezension

Re: svn commit: r1406719 - in /httpd/httpd/trunk: CHANGES docs/log-message-tags/next-number include/http_core.h server/core.c server/protocol.c

[Graham Leggett]

On 07 Nov 2012, at 10:35 PM, André Malo  wrote:

>> It feels wrong targeting 0.9 only, would it be possible to do this in a
>> generic way, say by listing the ones accepted, or by specifying a
>> minimum?
> 
> Hmm, what would be the use case? I see it with HTTP/0.9, but I don't see it 
> with >= HTTP/1.0. I'd prefer kind of "duck typing" for those, like 
> asking "is a valid host header present?" - which is already possible.

I've had problems in the past with HTTP/1.0 requests to restful services 
causing keepalive problems with load balancers, and I'd like to be able to ban 
HTTP/1.0 requests, allowing HTTP/1.1 only.

Regards,
Graham
--



smime.p7s
Description: S/MIME cryptographic signature