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.
This indicates to me that your root problem isn't a
MixedEncodingExceptionand 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
MixedEncodingExceptionyour 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.