fix: match parse_field header names only at line starts

[kugland]

Fixes #94.

Summary

• parse_field() used strcasestr over the whole request buffer, so any substring matching a header name was accepted — including bytes inside the request-target or another header's value. This let clients smuggle Authorization, Range, X-Forwarded-For, Host, If-Modified-Since, etc.
• Most impactful: with --trusted-ip, a client whose connection matches the trusted proxy address could spoof its logged IP by hiding X-Forwarded-For: <ip> inside a header it controls (e.g. Referer), without ever sending a real X-Forwarded-For.
• Fix: walk header lines and only match the field name at the start of a line (strncasecmp after each \n). The request line itself never matches a header name.

Repro (pre-fix, server started with --trusted-ip 127.0.0.1, client on 127.0.0.1):

printf 'GET / HTTP/1.0\r\nHost: x\r\nReferer: X-Forwarded-For: 99.99.99.99\r\n\r\n' \
  | nc 127.0.0.1 18080

logs 99.99.99.99 - - ... "GET / ..." 200 ... "X-Forwarded-For: 99.99.99.99" "". Post-fix, real client IP is logged.

Test plan

• Added test_xff_smuggled_in_referer to devel/test_log_xff.py. Fails on 7b9cafa (vulnerable), passes after the fix.
• All 5 existing test_log_xff.py cases still pass.
• Smoke-tested manually with --trusted-ip 127.0.0.1 for both the smuggling attempt and a legitimate X-Forwarded-For: 1.2.3.4 header.

[kugland]

I reordered the commits and force-pushed them, so you can checkout the one with the test but without the fix, and see it failing.

[g-rden]

Unless I'm mistaken the whole thing can be simply solved by changing

darkhttpd/darkhttpd.c

Line 1785 in 7b9cafa

if (pos == NULL)

to if (pos == NULL || (pos != conn->request && pos[-1] != '\n'))

[kugland]

Thanks for the suggestion, @g-rden! The check does correctly reject the smuggled case, but there's a subtlety: if the field name happens to appear as a substring inside a prior header's value and a real header with that name also follows, strcasestr finds the embedded occurrence first, the pos[-1] != '\n' guard rejects it, and the function returns NULL — silently losing the real header.

For example, if a request contains both Referer: http://evil.example/X-Forwarded-For: 99.99.99.99 and a real X-Forwarded-For: 10.20.30.40, your approach would log the direct connection IP instead of the real forwarded client IP. I added test_xff_real_header_not_masked_by_prior_value_match to cover this case — it fails with a single-hit approach but passes with the line-walking fix.

[g-rden]

What if the string for the field we compare the request with already contains a leading '\n'. There would be no need for any extra testing. The request fields that are passed to the function always follow a newline anyway IFAIK.

It would be as simple as:

char *request_field = NULL;

xasprintf(&request_field, "\n%s", field);
pos = strcasestr(conn->request, request_field);

But I night have missed something