php - What does the security implications for default character set in mysqli_real_escape_string() means? -
in php documentation mysqli_real_escape_string(), written that
caution security: default character set
the character set must set either @ server level, or api function mysqli_set_charset() affect mysqli_real_escape_string().
source mysqli_real_escape_string
in further link character set, mentioned that
the character set should understood , defined, has affect on every action, , includes security implications.
suource character sets
why necessary set character set sake of security , security implications include? can anyone, explain concept behind lines ?
thanks in advance
how sql queries parsed dependent on connection character set. if did query:
$value = chr(0xe0) . chr(0x5c); mysql_query("select '$value'");
then if connection character set latin-1 mysql see invalid:
select 'à\'
whereas if character set shift-jis, byte sequence 0xe0,0x5c interpreted double-byte character:
select '濬'
add string literal escaping security:
$value = mysql_real_escape_string($value); mysql_query("select '$value'");
now if you've correctly set connection character set shift-jis mysql_set_charset
, mysql still sees:
select '濬'
but if haven't set connection character set, , mysql's default character set shift-jis php's default character set ascii, php doesn't know trailing 0x5c character part of double-byte sequence, , escapes it, thinking generating valid output:
select 'à\\'
whilst mysql reads using shift-jis as:
select '濬\'
with trailing '
escaped backslash, has left string literal open. next '
character in query end string, leaving whatever follows in raw sql content. if can inject there, query vulnerable.
this problem applies few east asian encodings shift-jis multibyte sequences can contain bytes on own valid ascii characters backslash. if mismatched encodings both treat low bytes always-ascii (strict ascii supersets more-common mismatch of latin-1 vs utf-8), no such confusion possible.
luckily servers default these encodings uncommon, in practice rarely-exploitable issue. if have use mysql_real_escape_string
should right. (better avoid using parameterised queries though.)
Comments
Post a Comment