You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2017/10/27 10:01:48 UTC

[Bug 61676] New: Unable to handle unescaped whitespace in URL with HttpProtocolOptions Unsafe

https://bz.apache.org/bugzilla/show_bug.cgi?id=61676

            Bug ID: 61676
           Summary: Unable to handle unescaped whitespace in URL with
                    HttpProtocolOptions Unsafe
           Product: Apache httpd-2
           Version: 2.4.28
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: minor
          Priority: P2
         Component: All
          Assignee: bugs@httpd.apache.org
          Reporter: mail@oliwel.de
  Target Milestone: ---

The new option "HttpProtocolOptions Strict" prevents requests with an unescaped
whitespace such as:

   GET /Hallo Welt HTTP/1.0

or also   

   GET /index.php?paramHallo Welt HTTP/1.0

With an error message of: AH03448: HTTP Request Line; Excess whitespace
(disallowed by HttpProtocolOptions Strict

For my understanding, setting "HttpProtocolOptions = Unsafe" should bring back
the old behaviour but it seems like the URL parser is unable to handle the
extra whitespace:

AH03449: HTTP Request Line; Extraneous text found 'HTTP/1.0' (perhaps
whitespace was injected?)

Based on the comment in Bug 60738
https://bz.apache.org/bugzilla/show_bug.cgi?id=60783#c2, the Unsafe flag should
*not* turn of whitespace checking and all and keep with the original policy
error as quoted above. If still allowed with Unsafe, it should be properly
handled by the next layers.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 61676] Unable to handle unescaped whitespace in URL with HttpProtocolOptions Unsafe

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61676

Eric Covener <co...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Eric Covener <co...@gmail.com> ---
By default, the parser finds extra whitespace after Welt, not before it. This
part can be permitted with Unsafe.

But when you get farther, you still have a totally unexpected token since
"Welt" is interpreted as the version as the protocol uses spaces for
delimeters.

I don't think even under Unsafe we want to hunt around and try to sort
out that the next token looks more like an HTTP version.  Invalid and
malicious share too much.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 61676] Unable to handle unescaped whitespace in URL with HttpProtocolOptions Unsafe

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61676

--- Comment #2 from Oliver Welter <ma...@oliwel.de> ---
As I already wrote myself, I can understand to NOT fix it but then the
whitespace should already be rejected at the parser level and not pass thru
this stage.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 61676] Unable to handle unescaped whitespace in URL with HttpProtocolOptions Unsafe

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=61676

--- Comment #3 from Eric Covener <co...@gmail.com> ---
(In reply to Oliver Welter from comment #2)
> As I already wrote myself, I can understand to NOT fix it but then the
> whitespace should already be rejected at the parser level and not pass thru
> this stage.

Sorry, but i don't see how altering it further for this one doomed set of
input really helps. I don't think the externals are good here, but to me
ignoring leading/trailing whitespace is one thing (unsafe) but throwing
away or merging tokens is another entirely (doomed).  The errors are
simply reported as they're encountered, left to right.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org