URL content
Added by dab about 3 years ago
lighttpd/1.4.58 Linux Mint 18.3
I have a problem in 1.4.58 which I have not noticed in earlier versions from Apt repos (1.4.35).
URLs that contain encoded query data or path info fail if the encoding includes a line feed (%0A).
e.g. from access.log"GET /info.php?cmd=%20LIMIT%2050%20%0A HTTP/1.1" 400
info.php
<?php
print_r(phpinfo());
I first noticed this problem when trying to use adminer (https://www.adminer.org/) with lighty.
The problem occurs with any php script.
Replies (3)
RE: URL content - Added by gstrauss about 3 years ago
See server.http-parseopts. Since lighttpd 1.4.54, lighttpd enforces stricter standards on the contents of HTTP request line. %0A is rejected by "url-ctrls-reject" You can configure this on or off. Defaults is enabled.
If you need to encode arbitrary content in the URL, it is recommended that you base64-encode it or use some other complete encoding, rather than partial %XX url-encoding of specific characters. Passing url-encoded Ctrl chars, such as %00 or %0A, might fool naive target programs which treat the the url-decoded strings as C strings, or parse on line-ending and treat something with multiple lines as multiple commands when that was not what was intended by the site authors.
[Edit] lighttpd 1.4.35 is ancient and may contain known security bugs. Please encourage the maintainers of the Ant repos to provide the latest lighttpd release.
RE: URL content - Added by dab about 3 years ago
Thanks for the quick response.server.http-parseopts = ( "url-ctrls-reject" => "disable")
works fine and I assume that the other opts take on default values.
I note that when I apply this to only one directory using$HTTP["url"] that I get the message:
configfile-glue.c.300) DEPRECATED: do not set server options in conditionals, variable: server.http-parseopts
When was it deprecated and is there another way around this?
My preference is to only allow this for the Adminer urls (/admin/)
RE: URL content - Added by gstrauss about 3 years ago
Certain lighttpd options, particularly those about processing the request line, must be set before the request is parsed, so that they get applied to the parsing rules of the request line.
Waiting for the request line to be parsed, to then match a condition like /admin, is ... wait for it ... too late, since the request line has already been parsed.
lighttpd requires server.http-parseopts to be a global setting, applied before the request line is parsed.
Your problem is adminer being sloppy. Including " \n" (%20%0A) at the end of query string is sloppy. lighttpd provides a workaround (which potentially reduces security and is not the default), and you have confirmed that the workaround allows adminer to work for you. While you might want lighttpd to bend over backwards further, the proper answer is to fix the questionable behavior in the app, in this case adminer, or whatever is producing the request on the client side.