instead of `@root.encoding`.
And fallback to ASCII-8BIT when filesystem encoding is US-ASCII.
When `@root.encoding` is not compatible filesystem encoding,
`Encoding::CompatibilityError` raised at `webrick/httpservlet/filehandler.rb:341`.
So `DocumentRoot` must be compatible with filesystem encoding.
20200619T054159Z.fail.html.gz
```
1) Failure:
WEBrick::TestFileHandler#test_cjk_in_path [D:/tmp/mswin-build20200619-14304-utgij/ruby/test/webrick/utils.rb:72]:
exceptions on 2 threads:
webrick log start:
[2020-06-19 16:28:42] ERROR `/あ.txt' not found.
webrick log end
Filesystem encoding is Windows-31J.
<"200"> expected but was
<"404">.
---
<[]> expected but was
<["[2020-06-19 16:28:42] ERROR `/\xE3\x81\x82.txt' not found.\n"]>.
```
`prevent_directory_traversal` treats `path_info` as filesystem encoding.
So path_info should be filesystem encoding in request URL.
On some environments, fallback to ASCII-8BIT when EncodingError.
Chrome 75+ started to strictly enforce X.509 keyUsage against TLS server
certificates. Webrick supports generating instant self-signed
certificates for debugging purpose and these certificates lacks required
keyUsage for modern TLS. So adding the following keyUsages:
- digitalSignature (for server authentication)
- keyAgreement (for DH key exchange)
- dataEncipherment (for data encryption)
References:
- https://tools.ietf.org/html/rfc5280#section-4.2.1.3
- https://crbug.com/795089
- https://boringssl-review.googlesource.com/c/34604
While the stripping of header values is required by RFC 2616 4.2 and
RFC 7230 3.2.4, the squishing is not and can break things, such as
when one header contains an HMAC of another header.
Fixes Ruby Bug 7021.
8b96088a86
This is a follow up to d9d4a28f1c.
The commit prevented CRLR, but did not address an isolated CR or an
isolated LF.
Co-Authored-By: NARUSE, Yui <naruse@airemix.jp>
WEBrick::HTTPProxyServer implementes HTTP proxy using
WEBrick and Net::HTTP.
WEBrick accepts HTTP/1.0 clients and
Net::HTTP uses always HTTP/1.1.
However HTTP/1.1 supports chunked transfer coding HTTP/1.0 doesn't.
Chunked transfer coding doesn't require that
content-length before the content is sent.
But non-chunked transfer coding require content-length before
the content is sent.
So, when HTTP/1.0 clients connects WEBrick::HTTPProxyServer and
origin server returns chunked response,
WEBrick::HTTPProxyServer needs to store whole content to
know the length of it.
This patch do it using tempfile.
Remove extraneous spaces after the status code that is
non-compliant with RFC, i.e `HTTP 200 OK `, to unnecessary
confusion for WEBrick users, by a risk that WEBrick instances in
the wild will have server responses flagged as suspicious or
malicious due to a similar bug in [Cobalt Strike
misconfiguration].
Reported by Matt Tennis <mtennis@paloaltonetworks.com>
[Cobalt Strike misconfiguration]: https://blog.fox-it.com/2019/02/26/identifying-cobalt-strike-team-servers-in-the-wild/
So that a customized HTTPServer subclass can use it's own
Request/Response classes.
To apply the override, make a subclass of WEBrick::HTTPServer
and override the
`create_request_and_response(with_webrick_config)` method. The
method should return an Array of [request, response].
To check whether the Server supports this method (i.e. when
using older versions of WEBrick when needing this
functionality), you can ask the server if it responds to the
method
server.respond_to?(:create_request_and_response)
This is backportable.
[ruby-core:69604] [Feature #11266]
From: Julik Tarkhanov <me@julik.nl>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66452 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
OpenSSL complains abour our keys being small and weak :<
Make them big and strong with 2048-bit RSA keys and SHA256 digests
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66152 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The values of @header are expected to be all strings;
WEBrick::HTTPResponse::[]=(key, val) explicitly converts the second
argument to a string and assigns it to @header hash.
However, there were some points in WEBrick internal code that assigns
non-String to @header. This change fixes the issues.
The values are checked by `header_value =~ /\r\n/` in check_header.
The type confusion caused conflict with removal of `Object#=~`
[Feature #15231].
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65984 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Based on patch by akr [ruby-core:88477], use Tempfile.create
to avoid unnecessary unlink call. Unlike akr's original patch,
this does not change the return value of flush.
Thanks-to: Tanaka Akira <akr@fsij.org>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64363 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
They are assigned automatically when pushing gem file to rubygems.org.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64213 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This adds a password_hash keyword argument to
WEBrick::HTTPAuth::Htpasswd#initialize. If set to :bcrypt, it
will create bcrypt hashes instead of crypt hashes, and will
raise an exception if the .htpasswd file uses crypt hashes.
If :bcrypt is used, then instead of calling
BasicAuth.make_passwd (which uses crypt),
WEBrick::HTTPAuth::Htpasswd#set_passwd will set the bcrypt
password directly. It isn't possible to change the
make_passwd API to accept the password hash format, as that
would break configurations who use Htpasswd#auth_type= to set
a custom auth_type.
This modifies WEBrick::HTTPAuth::BasicAuth to handle checking
both crypt and bcrypt hashes.
There are commented out requires for 'string/crypt', to handle
when String#crypt is deprecated and the undeprecated version is
moved to a gem.
There is also a commented out warning for the case when
the password_hash keyword is not specified and 'string/crypt'
cannot be required. I think the warning makes sense to nudge
users to using bcrypt.
I've updated the tests to test nil, :crypt, and :bcrypt values
for the password_hash keyword, skipping the bcrypt tests if the
bcrypt library cannot be required.
[ruby-core:88111] [Feature #14940]
From: Jeremy Evans <code@jeremyevans.net>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64060 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Prevents response splitting and HTML injection attacks in
poorly-written applications which blindly pass along user input
in redirects.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63964 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* lib/webrick/httpresponse.rb (send_body_io): use seek if NotImplementedError
is raised in IO.copy_stream with offset.
* lib/webrick/httpservlet/filehandler.rb (multipart_body): ditto.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@63008 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Original patch by tenderlove (with minor style adjustments).
* lib/webrick/httpresponse.rb (send_header): call check_header
(check_header): raise on embedded CRLF in header value
* test/webrick/test_httpresponse.rb
(test_prevent_response_splitting_headers): new test
* (test_prevent_response_splitting_cookie_headers): ditto
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62968 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Reading entire request or response bodies into memory can lead
to trivial denial-of-service attacks. Introduce Fibers in both
cases to allow streaming.
WEBrick::HTTPRequest gains a new body_reader method to prepare
itself as a source for IO.copy_stream. This allows the
WEBrick::HTTPRequest object to be used as the
Net::HTTPGenericRequest#body_stream= arg for Net::HTTP.
For HTTP proxy response bodies, we also use a Fiber to
to make the HTTP request and read the response body.
* lib/webrick/httprequest.rb (body_reader): new method
(readpartial): ditto
* lib/webrick/httpproxy.rb (perform_proxy_request): use Fiber
to stream response body
(do_GET, do_HEAD): adjust call
(do_POST): adjust call and supply body_reader
* test/webrick/test_httprequest.rb (test_chunked): test
for IO.copy_stream compatibility
* test/webrick/test_httpproxy.rb (test_big_bodies): new test
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62966 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
WARNING! WARNING! WARNING! LIKELY BROKEN CHANGE
Pass a proc to WEBrick::HTTPRequest#body to avoid reading a
potentially large request body into memory during
authentication.
WARNING! this will break apps completely which want to do
something with the body besides calculating the MD5 digest
of it.
Also, keep in mind that probably nobody uses "auth-int".
Servers such as Apache, lighttpd, nginx don't seem to
support it; nor does curl when using POST/PUT bodies;
and we didn't have tests for it until now...
* lib/webrick/httpauth/digestauth.rb (_authenticate): stream req.body
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62965 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
While WEBrick::HTTPRequest#body provides a Proc interface
for streaming large request bodies, clients must not force
the server to use an excessively large chunk size.
* lib/webrick/httprequest.rb (read_chunk_size): limit each
read and block.call to :InputBufferSize in config.
* test/webrick/test_httpserver.rb (test_big_chunks): new test
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62963 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
"BadRequest" alone does not resolve correctly, it is in the
HTTPStatus namespace.
* lib/webrick/httprequest.rb (read_chunked): use correct exception
* test/webrick/test_httpserver.rb (test_eof_in_chunk): new test
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@62962 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
