Приведет ли плохая практика использования класса WordPress wpdb к угрозам SQL-инъекций?

#php #wordpress #sql-injection

#php #wordpress #sql-инъекция

Вопрос:

У предыдущего разработчика была плохая практика использования wpdb класса wordpress, используя его методы «чтения из базы данных» для фактической записи в базу данных … пример:

 $wpdb->get_results( "UPDATE `table` SET `column1`='$value1', `column2`='$value2' WHERE `coulmn3`= '$condition';",ARRAY_A ); 
  

То же самое делается с INSERT ; всегда использует get_results или get_row для вставки в базу данных. По-видимому, он / она не знал о insert update доступных методах and .

Хотя код работает нормально, мне было интересно, будут ли входные данные по-прежнему экранироваться классом wpdb или нет, и подвергнет ли это веб-сайт угрозам SQL-инъекций.

Если да, то каким будет быстрое решение для устранения этой дыры в безопасности?В файлах веб-сайта будет не менее 100 команд вставки / обновления, и будет сложно просмотреть каждую из них и перейти на правильный метод. Если нет других более простых / умных идей, я продолжу и отредактирую каждую вручную.

Ответ №1:

Запросы, если они такие, как в вашем примере, подвергаются SQL-инъекциям.

WordPress предлагает предотвратить внедрение SQL с помощью функции prepare класса WPDB.

  <?php $sql = $wpdb->prepare( 'query' , value_parameter[, value_parameter ... ] ); ?> 
  

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

Комментарии:

1. Будет ли prepare возможным решением каждая отдельная переменная сама по себе? т.е. $value1= $wpdb->prepare('%s',$value1); ? и сделайте то же самое с любыми переменными, используемыми в $condition . Тогда я могу сохранить вызовы метода запроса такими, какие они есть. Дело в том, что существует довольно много запросов, которые используют одни и те же переменные …. изменение каждого из них займет много времени.