WordPress PHP, зачем нужен метод esc_like для типа запроса LIKE?
Поэтому я немного озадачен, почему в WordPress есть такой метод, как esc_like(): https://developer.wordpress.org/reference/classes/wpdb/esc_like/ Совет заключается в том, что параметр, который будет использоваться LIKE, должен быть экранирован с помощью esc_like(), чтобы сделать его безопасным, например:
$wild = '%';
$find = 'only 43% of planets';
$like = $wild . $wpdb->esc_like( $find ) . $wild;
$sql = $wpdb->prepare( "SELECT * FROM $wpdb->posts WHERE post_content LIKE %s", $like);
Но почему:
$sql = $wpdb->prepare( "SELECT * FROM $wpdb->posts WHERE post_content LIKE %s", $like);
В этом случае было бы недостаточно правильно подготовить этот параметр LIKE? Я не понимаю, что может пойти не так без использования esc_like, и действительно ли что-то может вызвать уязвимость, если использовать его без этого метода esc_like.
Насколько я понимаю, $wpdb->prepare должно быть достаточно, но в последнее время я не уверен в этом.
Итак, главный вопрос заключается в том, представляет ли это очень серьезную угрозу безопасности, если я использую его без метода $wpdb->esc_like()?
Боюсь, вы просто что-то перепутали. страница, на которую вы ссылаетесь, говорит прямо противоположное: «Вывод не является безопасным для SQL» (выделено мной). Итак, нигде на этой странице не утверждается, что эта функция делает что-либо «безопасным». Просто удобнее и предсказуемее.
Ответы 2
Вы правы, что для предотвращения внедрения SQL вам нужно использовать параметр запроса.
Цель «экранирования» строки для LIKE не совпадает с целью предотвращения SQL-инъекций.
Символы % и _ являются подстановочными знаками в выражении LIKE. Но что, если вы хотите буквально сопоставить эти символы?
SQL предлагает решение:
https://dev.mysql.com/doc/refman/8.0/en/string-comparison-functions.html#operator_like
Чтобы проверить буквальные экземпляры подстановочного знака, перед ним следует escape-символ.
Экранирующий символ по умолчанию — \.
Господа, смотрите мой ответ. API-интерфейс SQL-драйвера WordPress странно обрабатывает это экранирование. Лучше использовать его как предусмотрено, а не делать экранирование для этих констант LIKE, иначе что-то может сломаться.
Ну, я смотрю документ и код здесь: developer.wordpress.org/reference/classes/wpdb/esc_like Я вижу, что пример использования показывает объединение его с подготовленным запросом, но я думаю, что это только для того, показать правильный порядок его применения, если вы используете его в подготовленном запросе.
WordPress использует уникальную и не полностью задокументированную схему для обработки $wpdb->prepare(). Отобразите некоторый SQL, подготовленный таким образом, и вы поймете, что я имею в виду — появляются длинные строки уникальных идентификаторов, которые позже выпрямляются на этапе ->execute().
->esc_like() является частью этой схемы. И, конечно же, многое из этого делается для профилактики инъекций.
Я не согласен. esc_like() имеет мало общего с предотвращением инъекций. Просто профилактика неожиданных результатов.
На этой странице документа посмотрите на источник. Просто добавьте косую черту C к
%,_,\\. Это означает, что в ключевом слове поиска будет экранироваться что-то вроде43%.