in_splunk: splunk token validation must be case-insensitive

[lecaros]

Changes validation of received Splunk token to be case-insensitive, as the Splunk HEC does.

fixes #9517

Backporting

• Backport to latest stable release. in_splunk: splunk token validation must be case-insensitive. Backport of #9518 #9519

---

Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

[edsiper]

@lecaros where we can confirm in Splunk docs that indeed auth token are not case sensitive ? (it does not sound normal since it's a security mechanism)

[lecaros]

@edsiper I agree on that, it's way easier to break it if it's case-insensitive.
I was looking into the docs, but couldn't find anything explicitly saying that.
https://docs.splunk.com/Documentation/Splunk/9.3.1/Data/UsetheHTTPEventCollector
https://docs.splunk.com/Documentation/Splunk/9.3.1/Security/CreateAuthTokens

However, I confirmed the behavior using latest image of Splunk, as explained in the repro.
If we don't want to do that, then we just need to update the docs instead of mirroring what Splunk is doing.

[cosmo0920]

Or, should we provide case-sensitive or case-insensitive option on in_splunk? This could preserve backward compatibility.

[lecaros]

As per Splunk docs, the tokens are GUID (UUID).

it generates the token in the form of a globally unique identifier (GUID)

https://docs.splunk.com/Documentation/Splunk/latest/Data/FormateventsforHTTPEventCollector

Based on RFC 9562, these are hexadecimal representations and, therefore, are case-insensitive.

Note that the alphabetic characters may be all uppercase, all lowercase, or mixed case, as per Section 2.3 of [RFC5234]. An example UUID using this textual representation from the above ABNF is shown in Figure 1.

https://datatracker.ietf.org/doc/html/rfc9562

@edsiper @cosmo0920, please let me know if this makes sense.

[cosmo0920]

https://datatracker.ietf.org/doc/html/rfc9562

@edsiper @cosmo0920, please let me know if this makes sense.

From the RFC:

UUIDs MAY be represented as binary data or integers. When in use with URNs or as text in applications, any given UUID should be represented by the "hex-and-dash" string format consisting of multiple groups of uppercase or lowercase alphanumeric hexadecimal characters separated by single dashes/hyphens. When used with databases, please refer to Section 6.13.

Yes, it makes sense to me.

[lecaros]

ping @edsiper. This is the one we discussed today.
Backport is here