0

We use an ESAPI security layer in our application. We also, by design, use a '%' character for wildcard searches passed from the browser side. This is a poor choice and has carried over as legacy design for easily constructing the sql to run on the backend.

Now, a '%' character in input is rejected by the ESAPI validator to prevent double encoding attacks. We are actively pursuing the idea to replace the '%' by something like '*'. But for the interim, to enable use of '%' for wildcard searches, we are weighing our options among these options:

1) Turning off the ESAPI canonicalizer. (Bad idea, leaves hole for double encoding.)

2) In the security layer, replace all '%' by some unlikely character right before the filter pass. Then change back. (Folks have different opinions on this; some think this is as good as having no defense for a double encoding attack, other think it has some value.)

3) In the front-end app, let the user input '%', but substitute them by '*' before submitting to the server. Will need to manipulate the '*' as '%' again in the DAO layer. Will require the most code changes in all UI code that can take the wildcard input.

Would like to invite answers on how to best solve this. Appreciate any help.

shasan
  • 178
  • 2
  • 13
  • Could you provide more input as to what kinds of characters are legal? – avgvstvs Jan 09 '18 at 17:28
  • Alphanumeric strings (starting in a letter) is the rule for the data being searched on. For wildcarding the search, we allow an arbitrary number of percentage characters at arbitrary positions. – shasan Jan 09 '18 at 18:52
  • Hmm... If alphanumeric, and only starting with a letter... That sounds like it could be a bug in ESAPI's PercentCodec. Could you share some of the offending input? – avgvstvs Jan 10 '18 at 15:10

1 Answers1

1

This is a poor choice and has carried over as legacy design for easily constructing the sql to run on the backend.

This indicates to me that your root problem isn't a MixedEncodingException and that its SQL injection. (SQLi)

Rewrite the queries on the backend to use PreparedStatements. The only guaranteed solution to prevent injection attacks is to properly encode for the correct context. Since you're using user-input to help construct a SQL query, the proper context is SQL.

As far as the MixedEncodingException your best bet is option 3. You could just HTML-Encode your percents. Alter % with % then in theory, your payload would only contain HTML-encoded data.

But keep in mind, any transformation you make on the client is visible to an attacker, and I would tug at this thread. Fix the SQLi first, worry about MixedEncoding later.

avgvstvs
  • 6,196
  • 6
  • 43
  • 74
  • This is not a SQL injection problem. The parameters are already substituted via PreparedStatements. What I meant by this was, that by allowing '%' we can plug the query string into sql as-is, since sql also uses '%' as its wildcard operator. – shasan Jan 10 '18 at 00:35
  • Well.... I won't change that part of the answer, because at least with the information given up front, my spider-sense tingled. I do think that HTML-Encoding the percents in this case is your best bet. – avgvstvs Jan 10 '18 at 14:02