StringIndexOutOfBoundsException on OAuth2AuthMechanism

[cunhafinrix]

Describe the bug

I'm seeing a StringIndexOutOfBoundsException when the Authorization header is not valid

Expected behavior

It should return an invalid header

Actual behavior

throwing StringIndexOutOfBoundsException

How to Reproduce?

We have an application deployed and we get the usual random worldpress requests trying to access our system, most of the requests don't cause any issues but from time to time we get a 500, the last time we saw the 500 error we noticed this error message on our logs java.lang.StringIndexOutOfBoundsException: begin 7, end 6, length 6. Looking at the entire error log we noticed that the error was being thrown inside elytron-security-oauth2 more specifically in here.

What is causing this error is the fact that the "malicious" user is not setting the Bearer token correctly. When the user sends an empty Bearer the code throws an error.

Output of uname -a or ver

No response

Output of java -version

21

Quarkus version or git rev

3.14.2

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

The error is caused by the string size not being checked before the substring method is called.

Potential solution

String authHeader = context.request().headers().get("Authorization");
String bearerToken = null;
if (authHeader != null && authHeader.length() > 7) {  // Ensure authHeader is long enough
    bearerToken = authHeader.substring(7);
}
if (bearerToken != null && !bearerToken.isEmpty()) {
    // Install the OAuth2 principal as the caller
    return identityProviderManager
            .authenticate(new TokenAuthenticationRequest(new TokenCredential(bearerToken, "bearer")));
}
// No suitable header has been found in this request,
return Uni.createFrom().nullItem();

[gsmet]

I think we should also check that the string starts with ´Bearer ´. Probably case insensitively.

Because atm, we are somehow implying it which is a bad idea.

[gsmet]

From what I can see here, we can be case sensitive: https://datatracker.ietf.org/doc/html/rfc6750#section-2.1

[gsmet]

#42595 should address it. Thanks for the very detailed report.