CEH Web Application and Injection Attacks Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use double URL encoding: '%25%35%35%25%34%65%25%34%39...'

  Why it's wrong here

  Double URL encoding involves encoding an already URL-encoded string, such as '%25%35%35' for '%55'. This technique attempts to bypass WAFs that perform only a single layer of decoding before signature inspection. However, modern WAFs are often configured to recursively decode multiple layers or are aware of common double-encoding patterns, rendering this method increasingly ineffective and unreliable against well-configured defenses.

• ✗

  Use hex encoding: '0x554e494f4e2053454c454354'

  Why it's wrong here

  Hex encoding, like '0x554e494f4e' for 'UNION', represents characters in hexadecimal format. While some SQL databases (e.g., MySQL) can interpret hex-encoded strings when explicitly cast or used in specific functions (e.g., CONVERT(0x... USING utf8)), it is not a universally recognized or automatically decoded format for keywords within a standard SQL query context. Therefore, simply injecting hex-encoded keywords directly into a query parameter will typically not be parsed as valid SQL by the database engine itself, making it ineffective for WAF evasion in this general scenario.

• ✗

  Use URL encoding: '%55%4e%49%4f%4e%20%53%45%4c%45%43%54'

  Why it's wrong here

  Standard URL encoding, such as '%55%4e%49%4f%4e' for 'UNION', is a fundamental web protocol mechanism for safely transmitting special characters in URLs. Web Application Firewalls are designed to operate at the application layer and therefore perform URL decoding as a primary step in their inspection pipeline. This ensures that the WAF analyzes the actual intended request content, rather than its encoded representation, making simple URL encoding ineffective for bypassing signature-based rules.

• ✓

  Use inline comments: 'UN/**/ION/**/SE/**/LECT'

  Why this is correct

  Inline comments, like '/**/', are valid SQL syntax that allows arbitrary text to be inserted without affecting query execution. By strategically placing these comments within keywords (e.g., 'UN/**/ION'), an attacker can break up the signature of a known malicious string (e.g., "UNION SELECT") into smaller, non-matching fragments. This technique effectively bypasses WAFs that rely on simple, exact string matching or regular expressions that do not account for such obfuscation, as the WAF sees 'UN', then '/**/', then 'ION', rather than the full "UNION" keyword.

Go deeper

Related to this question