Проблема безопасности/инъекция sql с сопоставлением mysql?

Возможно, у меня еще недостаточно понимания этого, поэтому я ищу небольшое направление.

Все наши таблицы показывают сопоставление latin1_swedish_ci. Вот что я вижу в переменных mysql:

collation connection utf8_general_ci
(Global value) latin1_swedish_ci
collation database latin1_swedish_ci
collation server latin1_swedish_ci

Теперь мы довольно часто видим utf8 (или, по крайней мере, контент на иностранном языке), хранящийся в БД, и он отображается правильно. Сопоставление не имеет значения для этого?

Использование чего-то вроде php addlashes() для пользовательского ввода - этого достаточно? Или это оставляет возможность инъекции?

РЕДАКТИРОВАТЬ: Итак, глядя на полный набор настроек сопоставления/кодировки, по крайней мере, в phpmyadmin, я вижу:

character set client    utf8
(Global value)  latin1
character set connection    utf8
(Global value)  latin1
character set database  latin1
character set filesystem    binary
character set results   utf8
(Global value)  latin1
character set server    latin1
character set system    utf8
character sets dir  /usr/share/mysql/charsets/
collation connection    utf8_general_ci
(Global value)  latin1_swedish_ci
collation database  latin1_swedish_ci
collation server    latin1_swedish_ci

mysql php security collation
person Neil    schedule 08.09.2010    source источник
comment
эти настройки ничего не значат. все они переопределяются. это просто значения по умолчанию. Проверьте кодировку конкретных таблиц. SHOW CREATE TABLE запрос может показать это   -  person Your Common Sense    schedule 09.09.2010
comment
Запуск таблицы show create для наших различных таблиц показывает charset по умолчанию = latin1. Однако на нашей стороне php мы устанавливаем тип выходного содержимого в utf-8. Таким образом, здесь может быть несоответствие, но все отображается правильно. . .   -  person Neil    schedule 09.09.2010

Ответы (2)


arrow_upward
2
arrow_downward

сопоставление описывает только правила сравнения символов определенный набор символов. Одно правило может заключаться в том, что a равно A, b равно B и т. д. или что ß равно ss, ä равно ae и т. д.

А для явного экранирования строк для MySQL используйте mysql_real_escape_string. Эта функция противоположна addslashes и mysql_escape_string учитывать фактическую кодировку символов соединения.

Но вам нужно установить кодировку символов соединения с помощью mysql_set_charset. Потому что в противном случае изменение не будет распознано (см. Описание функций C API — mysql_real_escape_string()):

Если вам нужно изменить набор символов соединения, вы должны использовать ссылку mysql_set_character_set() вместо выполнения оператора SET NAMES (или SET CHARACTER SET). mysql_set_character_set() работает как SET NAMES, но также влияет на набор символов, используемый mysql_real_escape_string(), которого SET NAMES нет.

person Gumbo    schedule 08.09.2010
comment
+1 это правильный ответ. хотя adodb и pdo используют mysql_escape_string() и всем нравятся параметризованные запросы... - person rook; 08.09.2010
comment
mysql_real_escape_string выполняет свою особую работу, только если используется mysql_set_charset(). в противном случае он будет действовать как mysql_escape_string - person Your Common Sense; 08.09.2010
comment
@полковник Шрапнель: Не знал. Но вы правы, см. dev.mysql .com/doc/refman/5.0/en/mysql-real-escape-string.html. - person Gumbo; 09.09.2010
comment
это могло бы быть эпическим провалом, если бы utf8 не был стандартом де-факто :) Но это так, и он не требует особого внимания от реального экранирования. Таким образом, mysql_real_escape_string в большинстве случаев является излишним. Не говоря уже о подготовленных операторах, на которые эта настройка вообще не влияет. - person Your Common Sense; 09.09.2010

arrow_upward
0
arrow_downward

Во всех наших таблицах сопоставление latin1_swedish_ci
содержимое на иностранном языке отображается правильно.

Что-то не так с вашей базой данных.
Она либо не сможет хранить нелатинские символы, либо не сможет правильно упорядочить/фильтровать содержимое базы данных.

Для хранения иностранных символов для таблиц должна быть установлена ​​кодировка utf8. А также кодировку подключения.

Использование чего-то вроде php addlashes() для пользовательского ввода - этого достаточно?

addlashes достаточно, если ваши кодировки только latin1 и utf8. Но в остальном неправильно.

  1. addlashes() или другие экранирующие функции сами по себе не помогают! Он работает только с кавычками вокруг экранированных данных. Таким образом, это должно быть не просто «Использование чего-то вроде addlashes ()», а «Использование чего-то вроде addlashes () для строк в кавычках и приведения типов для чисел»
  2. Не для ввода пользователем! Побег не для дезинфекции! Это просто для правильного форматирования запроса. Любой запрос. С любыми данными. Не только пользовательский ввод, как думают все в этом бедном мире, но и любые данные (которые отправляются в запрос в виде строк в кавычках).
person Your Common Sense    schedule 08.09.2010
comment
Спасибо за ответ. Я включил свои полные настройки кодировки/сопоставления выше, не уверен, что неправильно. Кроме того, я не уверен, какими будут настройки моих php-процессов, посмотрим, смогу ли я это понять. - person Neil; 09.09.2010