If you are faced with a “multiple URL encoding detected” or “multiple encoding detected” error, it can be somewhat confusing to troubleshoot, but this is a very fixable error. Let’s dig into to some likely causes and solutions.
Let’s level set by noting that this problem can happen in number of settings, but we’re going to focus on it happening within the context of a web application. If that’s not what you are encountering, please reach out as I’d be curious to learn about what you are seeing.
A “multiple encoding detected” error can happed in a number of ways, but the most common occurrence would be with your WAF (web application firewall), which is the software tool that is likely protecting your website or web application from the dangers of the open web. Through my research online, it seem’s like Microsoft’s Azure WAF is the most popular tool connected to this error, but it’s far from the only place where it can happen. You should be on the look out for this issue from any tool that is preventing injection of characters into a string, URL, form, etc.
Reblaze, the commercial WAF and API gateway protection tool, has a good write-up in their manual. They say this exception is in place because multiple encoding is “a common penetration technique is to encode a hostile request multiple times (for example, URL encode and base64), in an attempt to evade detection.”
And this makes sense right? If the developing is encoding their data in one way and then another encoding is observed, this seems a bit suspicious and it something that should probably be protected against.
Multiple encoding is sometimes known as “double encoding” so if you are researching exploits that used this technique or things to watch out for if you are protecting your application, make sure to search on both terms.
And, yes, this is used in the real world. Here are some recent multiple encoding exploits:
By double encoding strings it can be possible to do a script injection, transverse folders, and execute similar tactics.
The good news is that now that we know what’s happening, it should be relatively easy to look at your string (or more commonly URL) to find a section or sections that is/are causing the error.
A common culprit for this would be “%25” which is UTF-8 encoded “%” and another would be “%20” which is (famously) space. Additionally a benign seeming “¶m=” could be seen as an encoded “¶” which is a paragraph break (this thing: ¶).
These are examples where one string can be put in and another can be interpreted, which — as you can imagine — can have unintended consequences in the wrong hands. Your WAF is going to keep an eye out for things like this and thrown an error to help stop malicious behavior which you might have missed in your form, URL parameter, etc.
So how to fix this? Obviously you could disallow submission of anything problematic via the form or somewhere deeper in the application.
Another solution would be to create an exception in your WAF ruleset if the string that is creating the error isn’t going to be an issue for the app to process.
If you are seeing this error in your own development efforts and you have no reason to suspect an attempted script injection etc., then it should be easy enough to review the code (normally an attempted URL visit or POST with parameters on it), sanitize it, and then resubmit!
Sal April 6th, 2024
Posted In: Web Development
Tags: WAF