You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2024/04/16 07:18:03 UTC
Base64 and BASIC authentication
Hi all,
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
- allows embedded line breaks in the base64
- missing padding
- illegal characters in the base64 (ignored)
- illegal characters in the base64 padding (ignored)
- excessive padding
- whitespace around the decoded password
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?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Base64 and BASIC authentication
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Base64 and BASIC authentication
Posted by Mark Thomas <ma...@apache.org>.
On 16/04/2024 08:18, Mark Thomas wrote:
<snip/>
> Tomcat's current implementation is based on RFC 2617 and allows the
> following:
> - white space around the base64
> - allows embedded line breaks in the base64
> - missing padding
> - illegal characters in the base64 (ignored)
> - illegal characters in the base64 padding (ignored)
> - excessive padding
> - whitespace around the decoded password
>
> 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.
Just following up on this.
Prior to Tomcat 9.0.15, Tomcat always did this.
From 9.0.15 Tomcat did this by default but it could be disabled.
Intend to remove this feature from Tomcat 11 and disable it by default
in earlier versions.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org