Multiple (2x) encoding detected in from PercentCodec

[saravanansubiramaniam]

Our REST API receives the query parameters entered by the user. If the user wants to search for employees whose name ends with 2567, the query parameter looks like this: http://host:port/api?q=code.like('%2567') - so we use % for 'like' searches. However this causes error Multiple (2x) encoding detected in code.like('%2567')

Is this expected? If so, how should this search be supported?

Eg:
ESAPI.encoder().canonicalize("%2567");

[xeno6696]

Is this expected?

Yes.

If so, how should this search be supported?

This is much harder without understanding your application.
Your problem is that % in a URL has to be encoded to %25 because of syntax rules. And that '%' character also means something special in other languages like SQL.

I can't interpret your URL value. Please be much more explicit with your code examples. Your URL example and your encoder call don't make much sense because in a normal java application I would expect something that looks like this:

String query = request.getQuery("q");  // query.equals( "code.like('%2567')" )

So your example when thinking about traditional Java code is confusing. What's the exact URL? What's the value in debug JUST BEFORE it gets passed to ESAPI, and is it precisely a manual canonicalize call or are you passing it into a Validator method?

[planetlevel]

Add the % on the server side…. post-canonicalization. —Jeff Jeff Williams 410-707-1487

…

________________________________ From: Matt Seil ***@***.***> Sent: Tuesday, May 10, 2022 6:19:38 PM To: ESAPI/esapi-java-legacy ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [ESAPI/esapi-java-legacy] Multiple (2x) encoding detected in from PercentCodec (Issue #692) Is this expected? Yes. If so, how should this search be supported? This is much harder without understanding your application. Your problem is that '%' in a URL has to be encoded to %25 because of syntax rules. And that '%' character also means something special in other languages like SQL. I can't interpret your URL value. Please be much more explicit with your code examples. Your URL example and your encoder call don't make much sense because in a normal java application I would expect something that looks like this: String query = request.getQuery("q"); // query.equals( "code.like('%2567')" ) So your example when thinking about traditional Java code is confusing. What's the exact URL? What's the value in debug JUST BEFORE it gets passed to ESAPI, and is it precisely a manual canonicalize call or are you passing it into a Validator method? — Reply to this email directly, view it on GitHub<#692 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAUUFTETSHRRT556K5GZ4ITVJLOHVANCNFSM5VQNAQWA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[xeno6696]

^^^That's more or less where I'm headed, but I wanted to understand a little bit more.

[kwwall]

@saravanansubiramaniam - I had previously asked in the last 2 sets of ESAPI release notes for people to NOT ask questions in the GitHub issues forum. Our reasons for this is not because want to frustrate you or be uncivil, but rather because GitHub issues add a significant amount of overhead. First off, once we've decided that they have been adequately answered (something that often is very difficult for us to judge), we want to "close" the issue so the ESAPI team doesn't keep revisiting it. Secondly, we generally pull a list of the GitHub issues closed since a previous ESAPI release into our current release notes, but we don't really want to include issues that are, well, simply "questions". (That is why I labeled this issue as 'question'.)

I am going to copy your original question and relevant parts of the attempted answers over to the new Discussions area. In the future, please create a new Discussion with the category of 'Q&A' when you have a question and we will gladly attempt to answer it there. Plus it is a great way for us to build up a useful FAQ that we can post somewhere on our GitHub wiki or OWASP ESAPI wiki page.

In the meantime, you will find this discussion moved to Discussion #694.