Canonicalize() bug even worse in Guard 3.x

dev
1

With Guard extension 3.x the replace all ‘%’ with ‘%25’ workaround from 2022 doesn’t work anymore and we’re back to the error:

URLDecoder: Incomplete trailing escape (%) pattern

This has been a known bug for four years.

It has even been in Jira since 2023, but its status is still Backlog.

There even appears to be a failing test for it.

@GianTschingt … your analysis?

2

Thanks Kenric, good catch, and sorry this one has sat so long. I’ll reproduce it against Guard 3.x on 7.1.1.17 and the 7.1.2 RC, check it against LDEV-4743 and the failing test, and report back here with the cause and a fix plan.

3

Thanks Kenric, and sorry this one sat so long. Found it: in Guard 3.x, canonicalize() ended up using Java’s strict URL decoder, which throws on any % that isn’t a valid escape. Because 3.x decodes in a loop, your old %25 workaround fails too: %25 turns into % on the first pass and the next pass throws. The fix keeps a bare % as is and still decodes valid escapes, as ESAPI did in Guard 2.x. It’s in lucee/extension-esapi#19 with the LDEV-4743 test enabled, and it’s in QA now. It’s an extension-only fix, so once a new Guard version is released you can update it without changing your Lucee version. I’ll post here when it’s available.

4

Related: Lucee 6.0.x.x Canonicalize Exception
Thank you @kenricashe @GianTschingt

1 Like
5

Guard 3.1.0.7 is out with the fix: GitHub release / Maven Central. canonicalize() now leaves a bare % as is and still decodes valid escapes, like Guard 2.x did, so you can drop the %25 workaround. decodeFromURL() got the same fix. It’s an extension-only update, so no Lucee upgrade is needed. Let me know if anything still trips it up.