mysql中"set character_set_client=BINARY"的作用到底是什么？

danieluec

rt，為了防止寬字節(jié)，很多資料上都說可以在客戶端設(shè)置“set character_set_client=BINARY”，但是這句話的含義到底是什么呢？假如我目前客戶端的程序是這么設(shè)置的：
<?php

mysqli_query($conn, "set character_set_connection=GBK,set character_set_results=GBK,set character_set_client=BINARY");

...
...
?>

seesea2517

沒怎么用過php，不過看著應(yīng)該就用 set names 來統(tǒng)一設(shè)置三者字符集就可以了。
你這個設(shè)置是客戶端單獨(dú)用不同的字符集，二進(jìn)制字符集就是不做轉(zhuǎn)換，直接存儲、傳輸字節(jié)內(nèi)容。由于你的配置里連接用的是 GBK，那么傳到客戶端來的數(shù)據(jù)也就用 GBK 來解釋了。

BINARY：二進(jìn)制字符集相關(guān)說明：https://dev.mysql.com/doc/refman/5.7/en/charset-binary-set.html
php 連接設(shè)置的FAQ：https://dev.mysql.com/doc/refman ... gui-not-display-cjk

danieluec

@seesea2517 謝謝了！如果用“set names GBK”的話，是存在寬字節(jié)注入漏洞的。比如發(fā)起請求"http://xxx.com/index.php?a=%df'"。經(jīng)服務(wù)端轉(zhuǎn)義后，a的值會變成%df%5c'，而%df%5c是一個漢字，這相當(dāng)于把單引號給逃離出來了，可以發(fā)起sql注入攻擊。
如果設(shè)置“character_set_client=BINARY”，即使“不做轉(zhuǎn)換、直接存儲”，那么mysql在解析sql之前，sql中a的內(nèi)容還是%df%5c'，按照這個邏輯，按說還是存在漏洞的。因此還是想不明白在防御攻擊的角度上，這個binary為什么能防住。

danieluec

@seesea2517 謝謝了！如果用“set names GBK”的話，是存在寬字節(jié)注入漏洞的。比如發(fā)起請求：

1. http://xxx.com/index.php?a=%df'

復(fù)制代碼

經(jīng)服務(wù)端轉(zhuǎn)義后，a的值會變成%df%5c'，而%df%5c是一個漢字，這相當(dāng)于把單引號給逃離出來了，可以發(fā)起sql注入攻擊。
如果設(shè)置“character_set_client=BINARY”，即使“不做轉(zhuǎn)換、直接存儲”，那么mysql在解析sql之前，sql中a的內(nèi)容還是%df%5c'，按照這個邏輯，按說還是存在漏洞的。因此還是想不明白在防御攻擊的角度上，這個binary為什么能防住。

danieluec

謝謝了！如果用“set names GBK”的話，是存在寬字節(jié)注入漏洞的。比如發(fā)起請求：

1. http://xxx.com/index.php?a=%df'

復(fù)制代碼

經(jīng)服務(wù)端轉(zhuǎn)義后，a的值會變成%df%5c'，而%df%5c是一個漢字，這相當(dāng)于把單引號給逃離出來了，可以發(fā)起sql注入攻擊。
如果設(shè)置“character_set_client=BINARY”，即使“不做轉(zhuǎn)換、直接存儲”，那么mysql在解析sql之前，sql中a的內(nèi)容還是%df%5c'，按照這個邏輯，按說還是存在漏洞的。因此還是想不明白在防御攻擊的角度上，這個binary為什么能防住。

danieluec

謝謝了！如果用“set names GBK”的話，是存在寬字節(jié)注入漏洞的。比如發(fā)起請求：

1. http://xxx.com/index.php?a=%df'

復(fù)制代碼

經(jīng)服務(wù)端轉(zhuǎn)義后，a的值會變成：

1. %df%5c'

復(fù)制代碼

而%df%5c是一個漢字，這相當(dāng)于把單引號給逃離出來了，可以發(fā)起sql注入攻擊。
如果設(shè)置character_set_client=BINARY，即使不做轉(zhuǎn)換、直接存儲，那么mysql在解析sql之前，sql中a的內(nèi)容還是：

1. %df%5c'

復(fù)制代碼

按照這個邏輯，按說還是存在漏洞的。因此還是想不明白在防御攻擊的角度上，這個binary為什么能防住。

danieluec

謝謝了！如果用“set names GBK”的話，是存在寬字節(jié)注入漏洞的。比如發(fā)起請求：

1. http://xxx.com/index.php?a=%df’

復(fù)制代碼

經(jīng)服務(wù)端轉(zhuǎn)義后，a的值會變成：

1. %df%5c’

復(fù)制代碼

而%df%5c是一個漢字，這相當(dāng)于把單引號給逃離出來了，可以發(fā)起sql注入攻擊。
如果設(shè)置character_set_client=BINARY，即使不做轉(zhuǎn)換、直接存儲，那么mysql在解析sql之前，sql中a的內(nèi)容還是：

1. %df%5c’

復(fù)制代碼

按照這個邏輯，按說還是存在漏洞的。因此還是想不明白在防御攻擊的角度上，這個binary為什么能防住。

danieluec

謝謝~
從安全的角度看，如果二進(jìn)制字符集就是不做轉(zhuǎn)換、直接存儲、傳輸字節(jié)，那么按照mysql的編碼轉(zhuǎn)換流程（client->connection->server），將client的編碼設(shè)置為binary也是防不住注入漏洞的。所以想弄明具體binary的功能和整個編碼過程。

seesea2517

回復(fù) 20# danieluec

防注入應(yīng)該有一些相關(guān)的專題文章或討論，樓主有發(fā)現(xiàn)有價值的歡迎分享給大家哈。

王楠w_n

回復(fù) 1# danieluec

回帖以標(biāo)注成精華帖，感謝您對社區(qū)內(nèi)容的貢獻(xiàn)