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.

  • 2
    I don't understand what was bypassed, if Base64 characters are valid according to validation then the input was valid. There is some kind of huge fundamental misunderstanding here.
    – Esailija
    Commented Apr 16, 2013 at 21:00

4 Answers 4


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.

  • From WAF perspective is there any way is there any way to identify Application encoding scheme.
    – Ali Ahmad
    Commented Apr 17, 2013 at 3:30
  • Not really in an automated fashion... about all you can do is collect data for an input field and if all the accepted data is valid in a certain known standard encoding, assume that that encoding is worth decoding. Doesn't help for the body of encodings that don't have many invalid sequences though.
    – bobince
    Commented Apr 17, 2013 at 23:24

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.


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.

  • 1
    There are in principle an infinite number of encoding schemes, because even with a finite set of encodings, there can be unlimited combinations of multiple encodings (or the same encoding multiple times). Some WAF tools will indeed try to find 'bad' patterns that have been multiply-encoded (although obviously only to a configured limit rather than exhaustively), with diminishing returns.
    – bobince
    Commented Apr 16, 2013 at 20:52
  • Maybe, but not in practice. shrugs Firewalls that look for this type of stuff generally look at it two ways; known encoding schemes and statistical algorithm analysis. Everything is everything 'in theory', that doesn't make it a good idea to try and identify it all. IMO.
    – grauwulf
    Commented Apr 17, 2013 at 14:45
  • Indeed it's not a good idea, but that doesn't stop some tools doing it! (eg: ESAPI.) I guess with WAFs if you're going to do something largely ineffective you might as well do it really thoroughly ;-)
    – bobince
    Commented Apr 17, 2013 at 23:21

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .