Когда необходимо вставлять двойные кавычки и другие символы при вставке их в базу данных MySQL?

Question

Когда необходимо избегать двойных кавычек и / или специальных символов при вставке в текстовое поле в MySQL?

Предполагается, что у вас есть текстовое поле, содержащее описания или статьи, которые имеют двойные кавычки и / или амперсандынеобходимо ли экранировать их перед записью в таблицу базы данных?

Answer 1

MySQL (нестандартно) позволяет использовать двойные кавычки в качестве разделителей строковых литералов:

SELECT * FROM Accounts WHERE first_name = "Mel"

У вас возникнут проблемы, если вы интерполируете контент в строковый литерал SQL, а ваш контент содержит двойные кавычки:

SELECT * FROM Articles WHERE description = "She said, "Murder"!"

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

UPDATE Accounts SET PASSWORD = "..." WHERE account_name = "Mel" OR "X"="X"

Это может произойти, если злоумышленник утверждает, что его имя учетной записи Mel" OR "X"="X и это называется SQL-инъекция.

Но если вы избежите двойных кавычек в содержании, вы можете победить их вред:

UPDATE Accounts SET PASSWORD = "..." WHERE account_name = "Mel\" OR \"X\"=\"X"

Однако проще использовать параметры запроса, поэтому вы гарантируете, что содержимое отделено от кода SQL и никогда не приведет к непреднамеренным выражениям:

UPDATE Accounts SET PASSWORD = ? WHERE account_name = ?

Параметры позволяют вам подготовить запрос с заполнителями, а затем предоставить динамическое содержимое для каждого заполнителя при выполнении. Например, в PHP с PDO:

$sql = "UPDATE Accounts SET PASSWORD = ? WHERE account_name = ?";
$stmt = $pdo->prepare($sql);
$stmt->execute( array("...", "Mel") );

См. Мою презентацию Мифы и ошибки SQL-инъекций для получения дополнительной информации.

Answer 2

• Было бы необходимо кодировать двойные кавычки, только если вы добавляете строку в строковый литерал, ограниченный двойными кавычками.Но вы не должны использовать двойные кавычки-строковые литералы, потому что это странный нестандартный синтаксис MySQL, не поддерживаемый другими базами данных.

  Вместо этого используйте одиночные-кавычки-строковые литералы (например,name='Mel'), которые являются стандартом ANSI SQL и работают везде.И затем, конечно, вам нужно избегать одинарных кавычек в значении, а не двойных кавычек.

• Другой главный символ, который вам нужно экранировать в строковых литералах MySQL, - это \, поскольку MySQL используетэто как убегающий персонаж.Это более нестандартное поведение и довольно раздражающее.

Большинство сред webdev предоставляют вам экранирующую функцию SQL-string-literal, поэтому вам не нужно беспокоиться о том, какие именно символы нужныэкранирование для включения в запрос.Например, mysql_real_escape_string в PHP.Однако, как отметил Билл, вам лучше использовать параметризованные запросы там, где они есть, поэтому вам вообще не нужно беспокоиться об экранировании SQL.Ваш текст будет прыгать прямо в базу данных в виде необработанных строк без какого-либо промежуточного шага escape-unescaping.

Что касается амперсандов, они не являются специальными в строковых литералах SQL и должны быть экранированы not при созданиизапросы из строк.Они особенные в HTML, но вам не нужны данные в кодировке HTML в вашей базе данных.Вместо этого используйте функцию экранирования HTML (например, htmlspecialchars в PHP) в тот момент, когда вы вставляете строку в содержимое HTML, а не раньше.

Это распространенная ошибкаHTML-экранирование или «дезинфекция» содержимого на этапе ввода из отправки формы или на этапе построения SQL.Но это проблема стадии вывода HTML, которая должна решаться только на стадии создания шаблонов.

Answer 3

Вам не нужно избегать их перед сохранением в базе данных, но если вы пишете код для обработки пользовательского ввода , убедитесь, что прочитали и полностью понимаете риски SQL-инъекцииуязвимости или вы в мире зла.