Bypassing Web Application input validation

Question

A malicious user can use Base-64 or other encoding scheme to bypass web application input validation or to bypass some external Web application firewall. Since these encoding schemes are infinite how we can make these inputs finite to validate each and every input string.

Answer 1

The attacker doesn't get to choose what encodings might be effective. If there is no base64-decoder at the application end, performing base64 encoding will achieve nothing.

If there is a base64 decoding step at the application end, the application should be performing input validation after the decoding has been done.

In the case of WAFs, which sit in between and don't know what decoding the application might be doing, you're right - they're not reliable.

Some tools only apply the protocol-standard decoding (eg URL-decoding for URL parameters) and would false-negative on attacks encoded using an ad hoc scheme; some tools try a selection of encodings and optionally combinations n deep of encodings to try to spot attack signatures, which can lead to false positives as harmless text that will never be base64-decoded gets misinterpreted as the base64-encoding of something that could be an attack.

So yeah, fixes like WAFs that operate above the application layer are unreliable - but that's nothing new. Nobody should be relying solely on a WAF for security; they're good for detecting generic attacks, and for temporary custom workarounds for known vulnerabilities until an app fix is available, but they can never be a watertight input filter.

Answer 2

You don't validate input strings in abstracto. You validate strings for a specific purpose.

When a malicious user works around a validation system by using Base64, this means that the validation system, and the system which uses the value, don't agree. The validation system doesn't know about Base64, but the underlying system will happily apply Base64 decoding on the input. This is poorly done validation.

We could argue that "input validation" is more or less doomed to fail when done in a separate system (e.g. in a front-end), because two independently maintained pieces of software cannot be kept fully synchronized at all times. That's the generic issue with mysql_real_escape_string() in the PHP+MySQL context: that PHP function must be fully aware of all the fine details of how the underlying MySQL implementation will interpret input strings, and such details vary with the product versions.

Answer 3

I agree with @Thomas-pornin's post in regards to input validation but it is worth pointing out (RE: OP) that there aren't an infinite number of encoding schemes. There are a lot, but it's not an interminable system. When securing your applications it's important to research what encoding schemes are supported by your systems and tailor your security to the needs of your system, rather than trying to map every known codeset for every potential security concern. Unfortunately there is no 'golden hammer' to solve the problem of insecure data acquisition or management, so due care and due diligence are critical.

Best of luck with your work.

Answer 4

A malicious user usually trying to inject malicious code using XSS vulnerabilities or SQL injection, lets consider that you implemented prepared statement that prevents from SQL injection, then, the remaining possibility is XSS attack.

Malicious code for XSS contains JavaScript or any type of cross-origin embedding:

JavaScript with <script src="..."></script>
CSS with <link rel="stylesheet" href="...">
Images with <img>
Media files with <video> and <audio>.
Plug-ins with <object>, <embed> and <applet>.
Fonts with @font-face. Some browsers allow cross-origin fonts, others require same-origin fonts.
Anything with <frame> and <iframe>

From (Same-origin policy)

Now, consider that the user uses one of these methods, its known that allowing HTML is dangerous from user, considering that malicious user uses base65 encoding to obfuscate the code, but how this code can be executed? and why your system decodes base64?

Another scenario is when your application is uses user input to be used in third-party application, at this case, you can strictly tell user to follow allowed pattern, otherwise you could reject the input.