Какие символы регулярных выражений должны быть экранированы в SQL? - PullRequest
0 голосов
/ 31 августа 2018

Для предотвращения атаки с использованием SQL-инъекции в книге «Создание масштабируемых веб-сайтов» есть функция замены символов регулярного выражения на экранированную версию:

function db_escape_str_rlike($string) {
    preg_replace("/([().\[\]*^\$])/", '\\\$1', $string);
}

Эта функция экранирует ( ) . [ ] * ^ $? Почему в SQL экранированы только эти символы?

Ответы [ 2 ]

0 голосов
/ 03 сентября 2018

К сожалению, активные символы в базах данных sql остаются нерешенными. Каждый поставщик баз данных использует свои собственные (в основном, mysql оракула, который использует \ escape-последовательности)

Официальный способ SQL избежать ', который является строковым разделителем, используемым для значений, состоит в удвоении ', как в ''.

Это должен быть единственный способ обеспечить прозрачность в операторах SQL и единственный способ ввести правильный ' в строку. Как только любой поставщик признает \' в качестве синонима кавычки, вы открыты для поддержки всех дополнительных escape-последовательностей для разделения строк. Предположим, у вас есть:

'Mac O''Connor' (should go into "Mac O'Connor" string)

и предположим, что единственный способ избежать ' заключается в том, что ... тогда вы должны проверить следующий символ, когда увидите ' для последовательности '' и:

  • вы получите '', которое вы измените на '.
  • вы получаете другой, и завершаете строковый литерал и обрабатываете символ как первый из следующего токена.

Но если вы также признаете \ как escape, то вы должны проверить \' и \\', \\\' (последний должен быть преобразован в \' на входе) и т. Д. могут возникнуть проблемы, если вы не обнаружите особые случаи как

  • \'' (должен ли '' обрабатываться как мандаты SQL, или первый \' экранирует первый ', а второй - кавычка конца строки?)
  • \\'' (если \\ преобразовать в один \, тогда ' должен быть символом завершения строки, или мы должны переключиться на способ кодирования SQL и рассматривать '' как один цитата?)

и т.д.

Вы должны проверить документацию базы данных, чтобы узнать, влияют ли \ на управляющие символы только на кодировку специальных символов (например, управляющих символов и т. П.), А также влияет на интерпретацию символа кавычки или просто нет, и вам нужно сбежать ' в другую сторону.

По этой причине поставщики должны включать функции для экранирования / отмены символьных литералов в значения, которые должны быть встроены в оператор SQL. Идея злоумышленников состоит в том, чтобы включить (если вы правильно не делаете) escape-последовательности в данные, которые они публикуют, чтобы посмотреть, позволяет ли это изменить текст команды sql, просто добавив точку с запятой ; и записав полный SQL-оператор, который позволяет им свободно обращаться к вашей базе данных.

0 голосов
/ 01 сентября 2018

Я нашел отрывок из книги, о которой вы упомянули , и обнаружил, что эта функция не предназначена для защиты от уязвимостей SQL-инъекций. Я предположил, что это было, и временно ответил на ваш вопрос с учетом этого. Я думаю, что другие комментаторы делают то же самое предположение.

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

Это не имеет ничего общего с SQL. Вам нужно было бы экранировать те же символы, если вы хотите искать их буквально, используя grep, sed, perl, vim или любую другую программу, которая использует поиск по регулярному выражению.

...