mysql_real_escape_string bypass?

Hej!

Jag har suttit och letat lite hur man bypassar mysql_real_escape_string, och kom över denna sida: http://shiflett.org/blog/2006/jan/ad...-escape-string

Grejen är den att jag fattar inte hur jag ska använda '0xbf27' som han skriver.
Skriver jag det i URL'en tex så får jag errorn:
Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (gbk_chinese_ci,IMPLICIT) for operation 'UNION'

Några tips eller så hur man ska göra?

http://www.flashback.org/showthread.php?t=691411

Databasen som du ska haxxa måste köra med tekenkodeningen gbk_chinese_ci för att du ska kunna lura mysql_real_escape_string(). Så det där funkar i stort sett bara på asiatiska websidor.

Du verkar kunna det här.. har du ingen mer utförligare info om hur just det där tecknet kan hjälpa?

Exempel:

$id = mysql_real_escape_string($_GET["id"]);
mysql_query("SELECT * FROM news WHERE id = $id");


Mata in... union select för att hämta databasinnehåll från annan tabell bypassar mysql_real_escape_string pga att inga special-tecken används och i bästa fall är koden även så dålig att den kan skriva ut det man vill.

news.php?id=50 union select password from users where id=1/*

Men om queryn istället ser ut såhär?


Då måste man använda specialtecken...

Det hela gick ut på att trixa med tekenkodningar och få en mulitbytecharacter att escapas på ett felaktigt sätt så att slashen innan quoten blev någon helt annan bokstav. Det funkade bara på vissa teckenkodningar, t.ex. SJIS, BIG5 och GBK. Teckenkodningar som främst används i asien. Sårbarheten fixades i mysql 5.0.22, 24 maj 2006.
http://dev.mysql.com/doc/refman/5.0/en/news-5-0-22.html


Även funktionen addslashes() var känslig för detta. Vet ej om den har fixats, men förmodligen har den det.

Otur att bara asiaterna var smittade av denna bug..

Intressant läsning trots det