| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| | |
HTTP header-field stricter validation
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was brought about by certain whitespace characters being allowed
that are not allowed in the HTTP standard.
Waitress would dutifully strip those whitespace characters and continue
on as if nothing mattered, however whitespace in HTTP messages does
matter and could allow for HTTP request smuggling if the front-end proxy
server does not agree with the back-end server on how to parse a HTTP
message.
This disallows things like this:
Content-Length: 10
Transfer-Encoding:[0x0b]chunked
Which would get parsed by a front-end server as a request with
Content-Length 10, and an invalid Transfer-Encoding header, but would
get parsed as a chunked request by Waitress.
|
| |/
|
|
|
|
|
|
| |
Currently it is used for header name/fields only, but this should get
expanded as necessary.
Other stuff from other parts of waitress may move here too to create a
sort utility library of useful RFC standards based functions.
|
| |\
| |
| | |
HTTP Request Smuggling Fixes
|
| | |
| |
| |
| |
| |
| |
| | |
Updating version to version 1.4.0 due to the many changes in this
release. If anyone has explicitly pinned 1.3.x they will need to opt-in
to receive the security fixes, which do come with big changes that may
cahnge how Waitress handles HTTP requests.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Waitress only supports a single Transfer-Encoding and that is chunked.
We will read the whole request into a temporary buffer and then remove
the header and set the Content-Length.
However HTTP desync/HTTP request smuggling attacks could potentially
provide multiple Transfer-Encoding headers that would not get
appropriately treated by waitress.
Waitress now treats the header as potentially containing multiple
values, and validates that the last encoding listed is "chunked".
At this time Waitress does not support any other encodings, and all
other requests will be rejected with a 501 Not Implemented error.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Instead of attempting to continue processing the request, we instead
raise a ParsingError and return a HTTP Bad Request to the client.
This also catches the case where two Content-Length's are sent, and are
folded together using HTTP header folding.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Waitress used to treat:
Foo : bar
As a valid header, however
https://tools.ietf.org/html/rfc7230#section-3.2 states that this is not
valid.
|
| | |
| |
| |
| |
| |
| | |
Previously this would not be properly enforced if the request was passed
to waitress in one go, and the request headers could be larger than the
administrator had allowed.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
https://tools.ietf.org/html/rfc7230#section-3.5 says that servers MAY
implement their parsers to use only the LF as a delimeter between lines,
however if the frontend server does NOT do the same you can potentially
allow a single HTTP request to be treated differently by the two
servers.
This issue can be used to cause HTTP request smuggling or HTTP desync
which may lead to vulnerabilities.
To increase robustness Waitress will no longer allow bare LF for HTTP
messages/headers and chunked encoding and instead now enforces that the
line endings at CRLF.
|
| | |
| |
| |
| |
| | |
Silences some warnings in my editor, and makes sure if it is subclassed
in the future we don't blow up in code somewhere.
|
| |/
|
|
|
|
|
|
|
|
| |
When we start sending out an exception that has happened we want to drop
any further pipelined requests that may be waiting. The way we do this
is by slamming the connection shut after we send the response to the
received request that has errored.
This avoids potential issues with attempting to parse the rest of the
data that is in the TCP/IP connection that may contain invalid data.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
Add GH actions
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This sets up Github Actions to be used. Right now alongside Appveyor and
Travis, but I am thinking this will eventually take over.
|
| |\ \
| |/
|/| |
Fix typos in command line usage text
|
| |/ |
|
| | |
|
| |\
| |
| | |
Bugfix: uri parsing
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The HTTP spec states that it is acceptable to send a request like:
GET //whatever/testing HTTP/1.1
This should get properly conveyed to the WSGI application, but due to
the way that urlsplit works in the standard library this did not happen
correctly. With this fix we pass through the original path as requested
by the client, and the WSGI application will be responsible for
collapsing multiple empty path segments as necessary.
Fixes #260
|
| |/ |
|
| |\
| |
| | |
move proxy headers to a middleware and return 400 for malformed values
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |\
| |
| | |
avoid converting the version to a string value "None", empty instead
|
| |/ |
|
| | |
|
| |\
| |
| | |
pull the trigger more often, increases throughput in some testing
|
| | | |
|
| |\ \
| | |
| | | |
fix resource warnings
|
