quiet more request parse errors unless debug enabled with
debug.log-request-header-on-error = "enable"
x-ref:
"invalid character in URI -> 400 config?"
https://redmine.lighttpd.net/boards/2/topics/9512
header field-names are required to be lowercase for HTTP/2
so specialize http_header_hkey_get() as http_header_hkey_get_lc()
for simpler comparison
lowercase field-names in http_headers[], as it does not matter for
buffer_eq_icase_ssn(), which is used with http_headers[] for HTTP/1.x
http_request_parse_header() specialized for HTTP/2 request headers
to be parsed as each field-name and value is HPACK-decoded; send headers
directly from HPACK decoder, rather than double-buffering in chunkqueue
http_request_headers_process_h2() for post-processing
augment simple strtoll() which allowed number to begin with '+'
This is not exploitable for HTTP Request Smuggling since lighttpd
mod_proxy sends "Connection: close" to backends, and other CGI-based
backends reconstitute CONTENT_LENGTH in the environment without '+'.
(thx Amit Klein, Safebreach)
group HANDLER_COMEBACK logic in http_response_comeback() and call it
from places that reset state in order to (sometimes partially) reprocess
a request. This includes error handler (server.error-handler),
r->handler_module when cgi.local-redir, and looping in
http_response_prepare() when modules make changes to the request and
return HANDLER_COMEBACK (e.g. mod_rewrite, mod_magnet, mod_cml)
Also, set r->conditional_is_valid closer to where elements are set
(and become valid for use in condition checks), and parse target
in http_request_parse() instead of http_response_prepare()
NB: r->tmp_buf == srv->tmp_buf (pointer is copied for quicker access)
NB: request read and write chunkqueues currently point to connection
chunkqueues; per-request and per-connection chunkqueues are
not distinct from one another
con->read_queue == r->read_queue
con->write_queue == r->write_queue
NB: in the future, a separate connection config may be needed for
connection-level module hooks. Similarly, might need to have
per-request chunkqueues separate from per-connection chunkqueues.
Should probably also have a request_reset() which is distinct from
connection_reset().
convert all log_error_write() to log_error() and pass (log_error_st *)
use con->errh in preference to srv->errh (even though currently same)
avoid passing (server *) when previously used only for logging (errh)
In some circumstances, if the character on the heap prior to the
beginning of the request is '\r', then it would be overwritten with '\0'
With default compiler flags, this does not appear to occur in practice
and we therefore believe it to be a low-probability vulnerability.
(thx Antonio Morales)
This issue was discovered and reported by GSL team member @
<https://github.com/antonio-morales>antonio-morales
<https://github.com/antonio-morales> (Antonio Morales)
reject requests with both Transfer-Encoding and Content-Length
as recommended in RFC 7230 Section 3.3.3.
strict header parsing is enabled by default in lighttpd. However,
if explicitly disabled in lighttpd.conf, lighttpd will continue to
accept Transfer-Encoding and Content-Length in the same request,
and will ignore (and remove) Content-Length before passing to backend.
UNSAFE: server.http-parseopts = ( "header-strict" => "disable" )
This is NOT RECOMMENDED since doing so disables other protections
provided by lighttpd strict http header parsing.
RFC7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
3.3.3. Message Body Length
[...]
If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to
perform request smuggling (Section 9.5) or response splitting
(Section 9.4) and ought to be handled as an error. A sender MUST
remove the received Content-Length field prior to forwarding such
a message downstream.
x-ref:
stricter request header parsing
https://redmine.lighttpd.net/issues/2985
reject whitespace following request header field-name and before colon
Such whitespace is forbidden in RFC 7230 Section 3.2.4.
strict header parsing is enabled by default in lighttpd. However,
if explicitly disabled in lighttpd.conf, lighttpd will continue to
accept (and re-format) such field-names before passing to any backend.
UNSAFE: server.http-parseopts = ( "header-strict" => "disable" )
This is NOT RECOMMENDED since doing so disables other protections
provided by lighttpd strict http header parsing.
(thx fedormixalich)
x-ref:
stricter request header parsing
https://redmine.lighttpd.net/issues/2985
Glenn Strauss