search

openwrt / uhttpd

[MIRROR] Tiny HTTP server
https://git.openwrt.org/?p=project/uhttpd.git;
9 stars 6 forks source link

uhttpd allows CR and LF within header values #7

Open kenballus opened 2 months ago

kenballus commented 2 months ago

From RFC 9110:

Field values containing CR, LF, or NUL characters are invalid and dangerous, due to the varying ways that implementations might parse and interpret those characters; a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding of that message.

uhttpd does not enforce this rule for CR and LF. This leads to a pretty poor interaction with certain load balancers. See https://github.com/litespeedtech/openlitespeed/issues/394 for more details.

The suggested fix here would be to either

  1. reject messages containing CR or LF within header values, or
  2. replace those characters with spaces before processing the request.
champtar commented 2 months ago

The suggested fix here would be to either

  1. reject messages containing CR or LF within header values, or
  2. replace those characters with spaces before processing the request.

Don't try to sanitize, just reject, it's way safer

kenballus commented 2 months ago

Agreed.

stokito commented 2 months ago

I remember that curl on parsing response headers specifically allows any line ending. Is anything dangerous to do this from a client perspective?

kenballus commented 2 months ago

It would depend on the context. Permissiveness often has associated risk, but changing default behavior in a program as popular as curl can have serious unintended consequences. Not sure what the path forward is on the client side (if anything).