Opcja character_set_client jest to, czego MySQL używa do zestawu znaków zapytań i danych wysyłanych przez klienta.
Domyślnie jest to utf8 w MySQL 5.5, 5.6 i 5.7 oraz utf8mb4 w 8.0.
Można go również zmienić globalnie w pliku opcji my.cnf lub na sesję przez USTAW NAZWY oświadczenie.
Dobrze jest jawnie ustawić tę opcję podczas łączenia, aby nie trzeba było przyjmować jej wartości domyślnej.
Odpowiedz na swój komentarz:
Obawiam się, że mylisz dwa różne przypadki iniekcji SQL. Istnieje ryzyko w przypadku korzystania z tych określonych pięciu zestawów znaków, ale nie jest to związane z wstrzykiwaniem SQL drugiego rzędu.
Ryzyko związane z zestawem znaków wynika z niektórych zestawów znaków wielobajtowych. Często wstawia się odwrotny ukośnik, aby zastąpić dosłowny znak cudzysłowu. Ale w niektórych zestawach znaków bajt odwrotnego ukośnika jest scalany z poprzednim bajtem, tworząc znak wielobajtowy. To pozostawia cytat bez ucieczki.
Wstrzykiwanie SQL drugiego rzędu jest zupełnie inne. Może wystąpić z dowolnym zestawem znaków. Dzieje się tak, gdy atakujący dodaje dane do Twojej bazy danych za pomocą legalnych środków, takich jak wypełnienie formularza. Wstawianie danych odbywa się bezbłędnie. Ale wartości, które wstawiają, zawierają składnię zaprojektowaną do wykorzystania niektórych późniejszych zapytań SQL.
Polega na tym, że programiści wierzą, że dane, które zostały już bezpiecznie zapisane w ich bazie danych, są w jakiś sposób „bezpieczne” do użytku bez odpowiedniej parametryzacji.
Przykładem wstrzykiwania SQL drugiego rzędu, który jest po prostu przypadkowy, a nie złośliwy, może być to, że dana osoba ma nazwisko „O'Reilly”, a nazwisko jest odczytywane przez kod i używane w kolejnym zapytaniu.
$name = $db->query("SELECT last_name FROM people WHERE id = 123")->fetchColumn();
$sql = "SELECT * FROM accounts WHERE account_owner_last_name = '$name'";
Jeśli nazwa zawiera dosłowny apostrof, zepsuje to drugie zapytanie w tym przykładzie.
