bump? Just was reminded by a thread on reddit (config unclear but
probably not  non-cfgi proxy as it's a PHP app)

If the proxy modules would trap it, and the encoded spaces were
happily accepted by other modules before the fix, can we let spaces
through mod_rewrite?

On Tue, May 9, 2023 at 6:18 PM Eric Covener <cove...@gmail.com> wrote:
>
> On Tue, May 9, 2023 at 3:14 PM Ruediger Pluem <rpl...@apache.org> wrote:
> >
> >
> >
> > On 5/9/23 8:01 PM, Eric Covener wrote:
> > > On Tue, May 9, 2023 at 11:51 AM Ruediger Pluem <rpl...@apache.org> wrote:
> > >>
> > >>
> > >>
> > >> On 5/9/23 4:33 PM, Yann Ylavic wrote:
> > >>> On Tue, May 9, 2023 at 2:10 PM Yann Ylavic <ylavic....@gmail.com> wrote:
> > >>>>
> > >>>> On Tue, May 9, 2023 at 12:55 PM Ruediger Pluem <rpl...@apache.org> 
> > >>>> wrote:
> > >>>>>
> > >>>>> On 5/9/23 12:16 PM, Eric Covener wrote:
> > >>>>>> Still getting feedback in the PR about breakage. Any thoughts on 
> > >>>>>> options here, like allowing spaces or encoding rather than failing?
> > >>>>>
> > >>>>> Allowing spaces is out of question for me as it creates an invalid 
> > >>>>> request and opens the door to response splitting. At best we
> > >>>>> could encode automatically. It is really a good question if we could 
> > >>>>> not make BCTLS the default.
> > >>>>
> > >>>> BCTLS by default looks fine to me, it changes the behaviour for users
> > >>>> that (used to) expect/handle decoded spaces in the query-string in
> > >>>> their scripts, but it's blocked now anyway..
> > >>>
> > >>> Hm, actually we don't really know where the backref is placed (either
> > >>> in the uri-path or in the query-string), so escaping unconditionally
> >
> > Good point. Hence I think the only options left are that people fix their 
> > configurations or
> > that we scan r->args and encode all spaces. But this leaves the question 
> > open: Encode to what? '+' or %20?
> > Maybe we can put this job somehow in splitout_queryargs? It would have 
> > access to the RewriteRule flags and
> > we could decide based on if RULEFLAG_ESCAPENOPLUS is set or not.
> >
> > Something along the following (partly pseudocode, not optimized):
> >
> > Index: modules/mappers/mod_rewrite.c
> > ===================================================================
> > --- modules/mappers/mod_rewrite.c       (revision 1909373)
> > +++ modules/mappers/mod_rewrite.c       (working copy)
> > @@ -854,6 +854,31 @@
> >             }
> >          }
> >
> > +        if (global_option_encode_spaces) {
> > +            if (flags & RULEFLAG_ESCAPENOPLUS) {
> > +                char *p1, p2;
> > +
> > +                p1 = apr_palloc(r->pool, strlen(r->args) * 3 + 1);
> > +                for (p2 = r->args; *p2; p2++) {
> > +                    if (*p2 == ' ') {
> > +                        strcpy(p1, "%20");
> > +                        p1 += 3;
> > +                    }
> > +                    else {
> > +                        *p1++ = *p2;
> > +                    }
> > +                }
> > +                *p1 = '\0';
> > +            }
> > +            else {
> > +                for (char *pos = r->args; *pos; pos++) {
> > +                    if (*pos == ' ') {
> > +                        *pos = '+';
> > +                    }
> > +                }
> > +            }
> > +        }
> > +
> >          rewritelog(r, 3, NULL, "split uri=%s -> uri=%s, args=%s", olduri,
> >                     r->filename, r->args ? r->args : "<none>");
> >      }
> >
> > >>> might lead to double-escaping in the uri-path. Maybe it's simpler to
> > >>> remove the check and leave it to mod_proxy only..
> > >>
> > >> Do we have an example config where this currently breaks that does not 
> > >> forward it to a proxy backend?
> > >
> > >>From some of the GH activity, I think there is some mod_proxy_fcgi
> > > sending to FPM and PHP. In this case the query is in an environment
> > > variable.
> > >
> > > Are spaces over proxy_http really that much of a smoking gun? Wouldn't
> > > any smuggling/splitting/desynch already be fatal if it's in the
> > > request line? It can't be terminated early if we only allow spaces.
> >
> > You mean if there are just spaces and no control characters? I am not sure 
> > if you can do smuggling without \r and/or \n, but
> > the HTTP RFC is strict about what is allowed in the request URL and literal 
> > spaces are definitely not allowed.
> > If we allow them we send a non RFC compliant HTTP request to the backend. I 
> > think we must not do this.
>
> I was assuming the 403s are coming from mod_rewrite, not the proxy
> modules, and that we'd only change the former.   But it's not 100%
> clear for the people following up in the PR.
>
> If it's true, the proxy modules would then still return an error
> before putting unencoded/decoded spaces into the query.



-- 
Eric Covener
cove...@gmail.com

Reply via email to