Mark,
On 4/16/24 03:18, Mark Thomas wrote:
TL;DR - we need to tighten up parsing of BASIC authentication headers.
When I switched out Tomcat's Base64 handling for the built-in JRE
handling, I noticed that BASIC authentication was using a very relaxed
version of the Base64 decoder. That seemed odd, so I replaced it with
the standard Base64 decoder. That broke a bunch of tests so I switched
to the MIME decoder (the most relaxed) which fixed most - but not all -
of the issues. Then I started look at what the tests were testing and
the relevant RFCs.
The current RFC for HTTP BASIC authentication is RFC 7617. This in turn
references numerous other RFCs, most notably RFC 7235 (HTTP
Authentication) and RFC 4648 (Base64). Taken together these require that
the format of the Authorization header is:
- The token "Basic"
- Exactly 1 space
- The base64 encoding of username:password
Tomcat's current implementation is based on RFC 2617 and allows the
following:
- white space around the base64
Meh. This doesn't seem too impactful. If any part of the credential
needs to contain whitespace, that whitespace will be base64 encoded and
therefore not-whitespace in the header value.
- allows embedded line breaks in the base64
Ew. -1 please
- missing padding
This seems okay to me. JWT as a very modern example of base64-encoded
data in HTTP allows missing padding just to save 1-3 bytes even though
the JWTs themselves are monstrous.
- illegal characters in the base64 (ignored)
- illegal characters in the base64 padding (ignored)
These these should probably no longer be ignored.
- excessive padding
Weird. I wonder if that was intentional.
- whitespace around the decoded password
Full -1 from me. Whitespace should be allowed as part of a username or
password and trimming it is inappropriate.
I don't see any of the above causing issues apart from the last one
which prevents the use of passwords with leading or trailing whitespace.
This is mostly of a cleaning up exercise so the switch to Java's base64
decoder is simpler.
Before I merge the change to use the JRE's Base64 encoder, I intend to
tighten up the parsing of Basic authentication headers. I intend to do
this for all currently supported versions.
Any objections?
None here.
Do the relevant RFCs say anything about the missing padding? If Java
allows us to accept pad-less values, I would allow that to continue.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
