Check headers for line feed/carriage return chars

HTTP Response Splitting
(https://www.owasp.org/index.php/HTTP_Response_Splitting) could
potentially allow an attacker that is able to inject content into a HTTP
header (Location tends to be used) to send a response that will be
treated differently by the receiving client.

The fix used here is to raise ValueError from within start_response(),
using something similar to what mod_wsgi does by validating the header
values (seen here:
https://github.com/GrahamDumpleton/mod_wsgi/blob/develop/src/server/wsgi_validate.c#L134-L168)

It's a seatbelt, applications should not be returning headers with
control characters within the header, but it's hard to argue against
such a small change when it could have a large security impact for
applications serving WSGI apps with waitress.

1 files changed, 4 insertions, 0 deletions

diff --git a/waitress/task.py b/waitress/task.py
index 7136c32..501547a 100644
--- a/waitress/task.py
+++ b/waitress/task.py
@@ -371,6 +371,10 @@ class WSGITask(Task):
                     raise AssertionError(
                         'Header value %r is not a string in %r' % (v, (k, v))
                     )
+
+                if '\n' in v or '\r' in v:
+                    raise ValueError("carriage return/line "
+                                     "feed character present in header value")
                 kl = k.lower()
                 if kl == 'content-length':
                     self.content_length = int(v)