Что mysql_real_escape_string () делает, что addlashes () не делает?

Question

Зачем нам нужны специфичные для БД функции, такие как mysql_real_escape_string ()? Что он может сделать, чего не делает addlashes ()?

На данный момент игнорируется превосходная альтернатива параметризованных запросов, это веб-приложение, которое использует addlashes (), все еще уязвимое для SQL-инъекций, и если да, то как?

Answer 1

Addslashes обычно недостаточно хорош для работы с многобайтовыми кодированными строками.

Answer 2

Добавляет косую черту к:

\x00, \n, \r, \, ', " and \x1a. characters.

Там, где addlashes только добавляет косые черты к

' \ and NUL

Статья Илиаса также довольно подробно описывает его функциональность

Answer 3

Резко недооцененный ответ Г.С. на самом деле довольно правильный.

Стандартный SQL использует удвоение, чтобы избежать буквального апострофа. Нестандартное использование обратного слеша в MySQL для экранирования является настройкой по умолчанию, но его можно отключить, и часто это происходит, в частности, в sql_mode ANSI.

В этом случае будет работать только удвоенный синтаксис, и любое приложение, которое вы используете addlashes (или другой специальный метод экранирования), сломается. mysql_real_escape_string будет использовать любой способ экранирования, который лучше всего подходит для sql_mode соединения.

Проблема многобайтовой кодировки также важна, если вы все еще используете те противные восточноазиатские кодировки, которые повторно используют младшие 128 символов, но тогда вы действительно хотите использовать вместо этого UTF-8. С другой стороны, \ n-экранирование не имеет значения, поскольку MySQL вполне может справиться с необработанным переводом строки в операторе.

Answer 4

mysql_real_escape_string делает намного больше , чем addslashes делает.

addlashes работает на чистом ascii, ничего не зная о базе данных. Это ускользает:

• ' → \'
• " → \"
• \ → \\
• ASCII 0 → \0.

mysql_real_escape_string Цель состоит в том, чтобы «создать допустимую строку SQL, которую можно использовать в операторе SQL». mysql_real_escape_string учитывает текущий набор символов соединения (поэтому вы всегда должны передавать допустимый объект $ mysql).

Это делает следующее (взято из документации MySQL C API):

• Кодирует: \, ', ", ASCII 0, \n, \r и Control+Z таким образом, чтобы не вызывать проблем
• гарантирует, что 0 байт завершает строку (в C api)
• может выполнять преобразование многобайтовых (ascii) в широкие символы, если в базе данных, связанной с $ mysql, используется набор широких символов.

Я действительно не знаю, как PHP хранит строки внутри, но суть в том, что все это доступно PHP, когда вы используете mysql_real_escape_string. Я предполагаю, что главное отличие состоит в том, что mysql_real_escape_string учитывает набор символов соединения , где addslashes не может (он даже не знает, к какой БД вы подключены).

Answer 5

somedb_real_escape_string() зависит от базы данных, addslashes() - нет.

В случае MySQL это означает:

mysql_real_escape_string () вызывает Функция библиотеки MySQL mysql_real_escape_string, который добавляет обратную косую черту к следующему символы: \ x00, \ n, \ r, \, ', "и \ X1a.

(Из руководства.)

Answer 6

Зачем нам нужны специфичные для БД функции, такие как mysql_real_escape_string ()?

На самом деле, в большинстве случаев мы этого не делаем.
Эта функция требуется для нескольких крайне редких кодировок, а также для предварительного выравнивания журналов и дампов mysql.

является ли веб-приложение, использующее addlashes (), исключительно уязвимым для SQL-инъекций?

Пока он использует любую однобайтовую кодировку или utf8 - , он абсолютно безопасен с addlashes ().

Что он может сделать, чего не добавляет addlashes ()?

Может защитить строковый литерал SQL в случае некоторых редких кодировок.

Однако он не может сделать это сам по себе. Сначала необходимо установить правильную кодировку, используя функцию mysql_set_charset(). Если бы эта функция не использовалась, mysql_real_escape_string() будет вести себя точно так же, как и addslashes() с точки зрения обработки набора символов - разницы не будет вообще .

Answer 7

PHP-функция mysql_real_escape_string, более или менее, спросит у mysql, какие символы необходимо экранировать , где функция addlashses просто добавляет обратную косую черту перед любой одиночной кавычкой ('), символ двойной кавычки ("), обратной косой черты () или NUL (байт NULL).

Два практических эффекта: addlashes имеет тенденцию плохо работать с многобайтовыми символами, и, что более важно, спрашивая mysql, какие символы нужно экранировать, вы избегаете возможной будущей совместимости. Использование асслашей похоже на жесткое кодирование пары конкретных символов в escape-последовательности.

Answer 8

Согласно инструкции PHP :

mysql_real_escape_string () вызывает библиотечную функцию MySQL mysql_real_escape_string, которая добавляет обратный слэш к следующим символам: \ x00, \ n, \ r, \, ', "и \ x1a.

Answer 9

Единственное реальное различие, о котором я знаю, состоит в том, что mysql_real_escape_string () будет учитывать набор символов базы данных при экранировании входной строки. Ни одна из функций не будет экранировать символы подстановки% и _, что по-прежнему оставляет сценарий открытым для некоторых SQL-инъекций.

Answer 10

Согласно моему пониманию, mysql_real_escape_string () выполняет работу более точно, поскольку она взаимодействует с db, чтобы сначала проверить, что нужно кодировать, а затем кодировать соответственно, не так ли? Так что там для этого работают более эффективно

почему вы хотите сначала выполнить добавление косых черт, а затем удалить эти косые черты, прежде чем показывать эти данные и все еще добавлять косые черты не так эффективно, как mysql_real_escape_string, используйте mysql_real_escape_string, если вы используете mysql_query, например функции db, для запросов или я думаю, что PDO с подготовкой это лучший способ, так как mysql_real_escape_string специфична для БД