According to standards, nul bytes are allowed and significant characters
in form field names. This practice is however discouraged since it may
lead to header parsing errors or be understood by servers as an attack
attempt. In addition, header syntaxes containing nul bytes are now
deprecated [1].

There is obviously an intention to support this feature in curl: apart
from limiting the length of a non nul-terminated name string, the name
length parameter of curl_mime_name() is supposed to allow it. Is it the
primary reason for this parameter ? Do we really want to allow such zero
bytes in names.

Currently, curl's mime API wrongly escapes those bytes as '\0'. This
should be changed as this won't have the expected result when parsed by
the server. There is only one alternative to transmitting a binary zero
byte in a header: Use of RFC 2047 escaping [2].

Both methods (escaping or not) have their pros and cons:

No escaping pros:

- Compatibility with the old form API (that currently does not work
properly anymore, BTW).

- No need of RFC 2047 support in the server.

Cons:

- May fool servers (parsing errors, false positive attack detection).

- Needs special support in libcurl's code (no curl_slist).

Escaping pros:

- No nul bytes in text (may use curl_slist).

- No "control" character in stream.

- No triggering of strange server behaviors or exploits.

Cons:

- The server must support it.

- The encoding character set must be known.

- The header length increases.

Your comments are welcomed about which solution to implement:

a) remove nul byte support.

b) include nul bytes in output stream.

c) encode words containing nul bytes as RFC 2047.

Thanks in advance.

[1] = https://tools.ietf.org/html/rfc2822#section-4.1

[2] = https://www.ietf.org/rfc/rfc2047.txt

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-09-19