t:base64decode is too strict (padding required, no partial decoding)

[M4tteoP]

t:base64decode does not perform the decoding when a not perfectly crafted base64 is provided.

Rule for logging:

SecRule REQUEST_HEADERS:test "@unconditionalMatch" "id:1011,phase:1,pass,t:base64decode,log,msg:'Phase 1: %{MATCHED_VAR_NAME} : %{MATCHED_VAR}'"

Test1: perfectly crafter base64: PFRFU1Q+
Request: curl -H "test: PFRFU1Q+" http://localhost:8090
Coraza: [msg "Phase 1: REQUEST_HEADERS:Test : <TEST>"]
Modsecv2: [msg "Phase 1: REQUEST_HEADERS:test : <TEST>"]

Test2: space in the base64: PFR FU1Q (common if the base64 gets urldecoded and the + becomes a space)
Request: curl -H "test: PFR FU1Q+" http://localhost:8090
Coraza: [msg "Phase 1: REQUEST_HEADERS:Test : PFR FU1Q+"]
Modsecv2: [msg "Phase 1: REQUEST_HEADERS:test : <T"]

Test3: base64 missing padding: PFRFU1Q
Request: curl -H "test: PFRFU1Q" http://localhost:8090
Coraza: [msg "Phase 1: REQUEST_HEADERS:test : PFRFU1Q"]
Modsecv2: [msg "Phase 1: REQUEST_HEADERS:test : <TEST"] (equivalent of PFRFU1Q=)

The comparison shows how modsec v2 implementation:

• Returns the conversion up to when an unexpected character is found
• Is resilient if the padding is not explicit

Being the decoding used to try to deobfuscate malicious payloads, I feel that could be beneficial to be less strict and try to match even partially decoded strings.

[anuraaga]

Perhaps this was caused by me. From what I could tell, there is a different forgiving base64 transformation, base64DecodeExt

#758

Though at the time I guess CRS didn't exercise the case to know exactly which implementation is preferred. It would be confirmed what the difference between those two transformations is supposed to be though.

[M4tteoP]

Thanks for the context Rag! I'm not sure because also Modsec v3 is behaving like Coraza, and If I am not wrong, the old decoding we had was basically the ported version of https://github.com/SpiderLabs/ModSecurity/blob/5b094c0ce9044044f740e135df2a60c5f0858d4d/others/mbedtls/base64.c#L144 (From ModSec v3).
Modsec v2 is behaving differently by using apr_base64_decode.

I think we can still make it a bit more flexible by relying on the standard library, I will give it a go