summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Prep v1.4.3v1.4.3Bert JW Regeer2020-02-022-1/+17
|
* Merge pull request from GHSA-73m2-3pwg-5fgcBert JW Regeer2020-02-022-6/+28
|\ | | | | Fix catastrophic backtracking in regular expression
| * Remove accidental backslashBert JW Regeer2020-02-021-2/+2
| | | | | | | | Noticed this while looking at other tests.
| * Add bad header that caused catastrophic backtrackingBert JW Regeer2020-02-021-0/+11
| | | | | | | | | | This lets us validate that we won't accidentally cause the same issue down the line if we mess with the regular expressions
| * Add header parsing tests with short headersBert JW Regeer2020-02-021-0/+11
| | | | | | | | | | | | | | | | While fixing the catastrophic backtracking a gap in tests led to a potentially bad regex being considered that would have caused issues with short header values. This now adds a test to make sure we don't regress.
| * Remove catastrophic backtracking in regexBert JW Regeer2020-02-021-4/+4
|/ | | | | | This updates the regular expression so that there is no longer a chance for it to end up catastrophically backtracking and locking up the process.
* Prep for 1.4.2v1.4.2Bert JW Regeer2020-01-021-1/+1
|
* Merge pull request #277 from Pylons/invalid-whitespace-contBert JW Regeer2020-01-025-6/+92
|\ | | | | Invalid whitespace in headers
| * Add CHANGES and bump version to 1.4.2Bert JW Regeer2020-01-022-2/+31
| |
| * Update RFC7230 regex with errata for header field-contentBert JW Regeer2020-01-022-1/+18
| |
| * Remove accidental stripping of non-printable charactersBert JW Regeer2020-01-022-3/+43
|/ | | | | | | | | | | Continuation/follow-up for: https://github.com/Pylons/waitress/security/advisories/GHSA-m5ff-3wj3-8ph4 which showcased the initial problem with the way that waitress was dealing with whitespace in headers. Additional testing by ZeddYu Lu also led to other potential issues with non-printable ascii characters that are stripped by default by Python's string.strip() function
* Prep v1.4.1v1.4.1Bert JW Regeer2019-12-241-1/+1
|
* Merge pull request from GHSA-m5ff-3wj3-8ph4Bert JW Regeer2019-12-246-25/+194
|\ | | | | HTTP header-field stricter validation
| * Add links to advisories for previous security issuesBert JW Regeer2019-12-231-0/+13
| |
| * Bump version numberBert JW Regeer2019-12-231-1/+1
| |
| * Add documentation for security issueBert JW Regeer2019-12-231-0/+14
| |
| * Define VCHAR/OBS_TEXT onceBert JW Regeer2019-12-231-2/+13
| |
| * Validate HTTP header-field more completelyBert JW Regeer2019-12-232-22/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * Add file with RFC7230 definitions/ABNF -> regexBert JW Regeer2019-12-231-0/+44
|/ | | | | | | | 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.
* Merge pull request from GHSA-g2xc-35jw-c63pv1.4.0Bert JW Regeer2019-12-2013-427/+777
|\ | | | | HTTP Request Smuggling Fixes
| * Version 1.4.0Bert JW Regeer2019-12-201-1/+1
| | | | | | | | | | | | | | 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.
| * Update CHANGES.txt and HISTORY.txt as appropriateBert JW Regeer2019-12-202-73/+151
| |
| * Allow end of chunk parser to be resumeableBert JW Regeer2019-12-192-9/+44
| |
| * Improve validation of Transfer-EncodingBert JW Regeer2019-12-193-1/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * Upon receiving invalid Content-Length bailBert JW Regeer2019-12-192-3/+23
| | | | | | | | | | | | | | | | 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.
| * Disallow BWS in header field-namesBert JW Regeer2019-12-192-0/+16
| | | | | | | | | | | | | | | | | | | | 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.
| * Properly enforce max_request_header_sizeBert JW Regeer2019-12-191-17/+31
| | | | | | | | | | | | 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.
| * Remove support for non CRLF line endingsBert JW Regeer2019-12-198-303/+408
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * Make sure all errors have a code/reasonBert JW Regeer2019-12-191-0/+4
| | | | | | | | | | Silences some warnings in my editor, and makes sure if it is subclassed in the future we don't blow up in code somewhere.
| * Upon processing errors, set Connection: close headerBert JW Regeer2019-12-193-28/+26
|/ | | | | | | | | | 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.
* Fix coverage reporting of subprocess in coverage 5.xBert JW Regeer2019-12-192-9/+8
|
* Bring coverage back to 100%Bert JW Regeer2019-12-191-3/+0
|
* Concatenate lines black reformattedBert JW Regeer2019-12-191-11/+7
|
* Blacken the entire code baseBert JW Regeer2019-12-1243-2781/+3245
|
* Merge pull request #262 from Pylons/workflowsBert JW Regeer2019-12-123-0/+113
|\ | | | | Add GH actions
| * Also run on PR'sworkflowsBert JW Regeer2019-09-193-3/+3
| |
| * Add macOS testingBert JW Regeer2019-09-191-0/+29
| |
| * Setup GH actionsBert JW Regeer2019-09-192-0/+84
| | | | | | | | | | This sets up Github Actions to be used. Right now alongside Appveyor and Travis, but I am thinking this will eventually take over.
* | Merge pull request #272 from JonathonReinhart/fix-usage-typosSteve Piercy2019-11-291-4/+4
|\ \ | |/ |/| Fix typos in command line usage text
| * Fix typos in command line usage textJonathon Reinhart2019-11-291-4/+4
|/
* Prep for 1.3.1v1.3.1Bert JW Regeer2019-08-271-1/+1
|
* Merge pull request #261 from Pylons/bugfix/uri_parsingBert JW Regeer2019-08-273-4/+62
|\ | | | | Bugfix: uri parsing
| * Add CHANGES.txt entry for bugBert JW Regeer2019-08-271-0/+14
| |
| * Add comment why this code existsBert JW Regeer2019-08-271-0/+7
| |
| * Allow requests with URI that starts with multiple slashesBert JW Regeer2019-08-271-4/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * Add failing tests for #260Bert JW Regeer2019-08-271-0/+24
|/
* Merge pull request #259 from Pylons/proxy-header-middlewareBert JW Regeer2019-07-2413-1000/+1295
|\ | | | | move proxy headers to a middleware and return 400 for malformed values
| * restore the old per-language coverage filesproxy-header-middlewareMichael Merickel2019-07-243-2/+13
| |
| * add proxy header testsMichael Merickel2019-07-197-22/+105
| |
| * support echoing more request info, not just body, in functional testsMichael Merickel2019-07-192-27/+64
| |