Не используется оператор php prepare, когда я не получаю информацию от пользователя - PullRequest
0 голосов
/ 15 декабря 2018

PS : я знаю, что лучше всего готовить пользовательские заявления все время, и это должно быть привычкой использовать готовые заявления.Итак, оставим это в стороне, пожалуйста, просто дайте мне знать технически что может пойти не так, если я не напишу нижеприведенный сценарий с prepare.

1. Яя не получаю никаких данных от пользователей или других файлов классов, и я не буду в будущем.

2. Я получаю данные от переменной в том же файле PHP (массив например).

Пример: ($myID будет жестко закодированной переменной в том же файле PHP)

$myID=12;

$wpdb->query("UPDATE `$table_name` SET `your_column_1` = 1 WHERE `myTable`.`your_column_id` = $myID");

Ответы [ 2 ]

0 голосов
/ 17 декабря 2018

Это плагин WordPress, и я буду использовать его только в админ-панели.Таким образом, проблема возникла из-за использования оператора «in», потому что трудно написать запрос, такой как столбец обновления, где цвет в («черный», «белый»).

Если вы разрабатываете дляWordPress, вы рассматривали возможность использования API wpdb?Это позволяет легко добавлять параметры в ваши SQL-запросы.

Пример использования параметров для предиката IN( ):

$colors_array = ["black", "white"];
$placeholders = array_fill(0, count($colors_array), "%s");
$placeholder_list = implode(",", $placeholders);
$wpdb->query( $wpdb->prepare( 
    "
        UPDATE $wpdb->stock
        SET quantity = 327
        WHERE color IN ($placeholder_list)
    ", 
    $colors_array
));

См. https://codex.wordpress.org/Class_Reference/wpdb#Protect_Queries_Against_SQL_Injection_Attacks

Iсогласитесь с советом Эда Коттрелла о том, что вы не должны идти на компромисс с безопасными методами программирования.Используйте наиболее безопасный метод и используйте его последовательно.

  • Вам не нужно тратить время на размышления о том, является ли какой-либо конкретный случай "достаточно безопасным", чтобы пропустить его с помощью безопасного метода.
  • Вам не нужно беспокоиться, если все еще безопасно после того, как ваши PHP-переменные больше не жестко закодированы.
  • Вам не нужно беспокоиться, что кто-то скопирует и вставит ваш код в качестве примера и использует его небезопасным способом.
0 голосов
/ 15 декабря 2018

Tl; DR Это очень плохая идея.Вы вводите долгосрочный риск, чтобы сэкономить несколько секунд кода.Весьма вероятно, что вы рано или поздно введете риск внедрения SQL-кода по мере развития вашего кода и данных.

Если вы:

  • чрезвычайноосторожно относитесь к проверке ваших данных,
  • крайне осторожно относитесь к построению ваших запросов,
  • абсолютно уверены, что ваши данные в безопасности и не содержат любого ввода пользователя (из любого источника)вообще, включая формы, датчики, API-интерфейсы, чистящие веб-сайты и т. д.) и
  • абсолютно уверены, что никто никогда не изменит ваши данные или ваш код (или не использует ваш код ненадлежащим образом), , включаяВы ,

Тогда мы можем сказать:

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

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

... и все, чтобы сэкономить несколько секунд времени на кодирование..

Краткая версия: либо (1) используйте подготовленные операторы для каждого запроса , который имеет какую-либо переменную информацию, либо (2) непросто понять, почему это правило.

...