Writing byte stream as jpeg format to disk
nobody at nowhere.com
Fri Aug 27 10:30:37 CEST 2010
On Thu, 26 Aug 2010 23:56:26 -0700, Bryan wrote:
>> follow our advice. Split using b'\r\n\r\n' and use the maxsplit=1
>> argument to make sure that you do not split on spurious b'\r\n\r\n'
>> sequences inside the JPEG body. Do not decode the bytes.
> Correct, and I'll add that this is a case where we might want to be better
> than correct. BaseHTTPRequestHandler in the Python standard library
> accommodates clients that incorrectly omit the '\r' and end header lines
> with just '\n'. Such apps have been seen in the wild. Since bare '\n'
> never appears in correctly formed HTTP headers, interpreting it as
> equivalent to '\r\n' doesn't break anything.
Yes it does. It breaks upstream filtering rules which are intended to
prohibit, remove or modify certain headers.
This class of attack is known as "HTTP request smuggling". By
appending a header preceded by a bare '\r' or '\n' to the end of
another header, the header can be "smuggled" past a filter which
parses headers using the correct syntax, but will still be treated as a
header by software which incorrectly parses headers using bare '\r' or
'\n' as separators.
The safest solution would be to simply reject any request (or response)
which contains bare '\r' or '\n' characters within headers, at least by
default. Force the programmer to read the documentation (where the risks
would be described) if they want the "fault tolerant" behaviour.
More information about the Python-list