Re: [users@httpd] Block access to "OPTIONS *"

2016-02-12 Thread Yann Ylavic 
Following up below users@ discussion on dev@...

On Fri, Feb 12, 2016 at 12:47 PM, Yann Ylavic  wrote:
> On Fri, Feb 12, 2016 at 10:47 AM, Daniel  wrote:
>> The typical way to block OPTIONS in 2.2 does not need mod_rewrite at all
>> IIRC. You just add this in your location/directory:
>> 
>> deny from all
>> 
>>
>> and will return 403 if you try OPTIONS method there
>
> That wouldn't work because the replies to OPTIONS requests happen
> before in the map_to_storage hook, that is before the authz hooks
> (Toomas tried that already).

That's what I observed in my testing with the following configuration:
>
>  # matches / and *
> 
>Deny from all  # 2.2
>Require all denied # 2.4
> 
>   
>
> For now I could only make it work with:
>   RewriteEngine on
>   RewriteOptions AllowAnyURI # for * to be taken into account by mod_rewrite
>   RewriteCond %{REQUEST_METHOD} OPTIONS
>   RewriteRule ^ - [R=405,L]
>   RewriteRule ^[^/] - [R=403,L]
> which should be the first rewrite rules for AllowAnyURI to not be
> "dangerous" for further rules (if any) failing to match the leading
> slash.

That's not an elegant solution...

So I tried this change:

Index: modules/http/http_core.c
===
--- modules/http/http_core.c(revision 1729486)
+++ modules/http/http_core.c(working copy)
@@ -271,7 +271,7 @@ static int http_create_request(request_rec *r)
 static int http_send_options(request_rec *r)
 {
 if ((r->method_number == M_OPTIONS) && r->uri && (r->uri[0] == '*') &&
- (r->uri[1] == '\0')) {
+ (r->uri[1] == '\0') && !ap_some_auth_required(r)) {
 return DONE;   /* Send HTTP pong, without Allow header */
 }
 return DECLINED;
--

so to bypass http_send_options() if OPTIONS is ed (here
ap_some_auth_required() is a misnomer (deprecated btw), what it really
does is returning whether there is a Limit on the requested method,
AIUI though).

But ap_some_auth_required() always return false here, because there is
no mod_authz_core's per_dir_config (at this hook/point only?), so the
function has nothing to check.

Any insight on whether or not this is a reasonable approach and why it
does not work much appreciated :)

Regards,
Yann.

Re: [users@httpd] Block access to "OPTIONS *"

2016-02-12 Thread Yann Ylavic 
On Fri, Feb 12, 2016 at 1:28 PM, Jim Jagielski  wrote:
> Blocking OPTIONS has a long and illustrious history...
> I am -0 on doing anything more related to it ;)

OK, I see, let's users@ play with the workaround then :)

Re: [users@httpd] Block access to "OPTIONS *"

2016-02-12 Thread Daniel Gruno 
On 02/12/2016 01:28 PM, Jim Jagielski wrote:
> Blocking OPTIONS has a long and illustrious history...
> I am -0 on doing anything more related to it ;)
> 

Isn't that why we have the optional mod_allowmethods these days anyway...

With regards,
Daniel.

Re: [users@httpd] Block access to "OPTIONS *"

2016-02-12 Thread Jim Jagielski 
Blocking OPTIONS has a long and illustrious history...
I am -0 on doing anything more related to it ;)

Re: [users@httpd] Block access to "OPTIONS *"

2016-02-12 Thread Yann Ylavic 
On Fri, Feb 12, 2016 at 1:29 PM, Daniel Gruno  wrote:
> On 02/12/2016 01:28 PM, Jim Jagielski wrote:
>> Blocking OPTIONS has a long and illustrious history...
>> I am -0 on doing anything more related to it ;)
>>
>
> Isn't that why we have the optional mod_allowmethods these days anyway...

That looks nicer indeed, but the user is running 2.2...
Anyway, he should upgrade to benefit latest improvements :p

Regards,
Yann.