As an example, note the following trivial Stored Procedure:
create procedure GetData ( @param varchar(20) ) as
begin
declare @s varchar(200)
select @s = 'select * from dataTable where name = ''' + @param + ''''
exec (@s)
end
This SP may be called from a Web page, which executes validation code
before passing the input to the SP. At a minimum, this validation code
either verifies that the input does not contain a quote, or sanitizes
it to double any existing quote. For instance, the validation code may
be using string.Contains()
, string.Replace()
, Regular expressions,
etc. It is also possible that this Web page is behind a finely-tuned
Web Application Firewall that validates all input and verifies that no
quotes are included. A malicious user or attacker can submit malicious
code containing a modifier letter apostrophe (U+02BC
, URL encoded to
%CA%BC
). This will easily pass applicative validation code and WAF
filters, since these search for an actual quote (U+0027
) which does
not exist in the input at this time. Obviously, IDS/IPS systems would
also not detect anything amiss. The validation mechanisms may even
search for various encodings of a quote, such as URL Encoding, UTF-8
encoding, Hex encoding, double encoding, and more – however, U+02BC
is
none of these, and is in fact a completely different character value.
And this is where the interesting (or scary) part starts – the Unicode
homoglyph translation is not limited to base alphabet characters...
Specifically, the Unicode character U+02BC (modifier letter
apostrophe) can be translated by the database server to a simple quote
– ' (U+0027). There are, of course, many other similar examples.