As noted by security@python.org's response I'm filing this bug here.


In wsgiref.headers.Headers it is possible to include headers which
contain a newline (i.e. \n or \r) either through add_header or
__init__. It is not uncommon that developers provide web applications
to the public in which the HTTP response headers are not filtered for
newlines but are controlled by the user. In such scenarios a malicious
user can use a newline to inject another header or even initiate a
HTTP response body. The impact would be at least equivalent to XSS.
Therefore, I suggest to filter/warn/except header tuples which contain
the above characters upon assignment in wsgiref.headers.

> It is not uncommon that developers provide web applications
to the public in which the HTTP response headers are not filtered for
newlines but are controlled by the user.

Really?  Which applications, and which response headers?

> Therefore, I suggest to filter/warn/except header tuples which contain
the above characters upon assignment in wsgiref.headers.

Applications that send them are not WSGI compliant anyway, since the spec forbids control characters in header strings -- and wsgiref.validate already validates this.

Still, I'm not aware of any legitimate use case for apps sending user input as an HTTP header where the data wouldn't already be escaped in some fashion -- cookies, URLs, ...?

If the spec forbids control characters in headers, the module should
enforce that.

The most frequent example of header injection is the redirect-case: an
application is forwarding using the Location header to a user-supplied
URL.
http://google.com/codesearch?as_q=self.redirect%5C%28self.request.get
Other examples are proxies, setting user-agent, or, as you mention,
custom set-cookies headers.