Достаточно ли использовать подготовленные запросы PDO PHP?

Question

[Андрей Рабой]

при приеме данных из формы, достаточно ли использовать подготовленные запросы? IDE рекомендует filter_input совмещать с is_*(). Слушаю все мнения)

public static function preExec($sql, $arr, $db) {
        $stmt = $db->prepare($sql);
        $stmt->execute($arr);
    }

    $arr[] = $_REQUEST['data'];
    $sql = 'UPDATE `sometb` SET `someval`=?';
    Class::preExec($sql, $arr, $db);

Comments

[FanatPHP]

два замечания.
1. вместо громоздкого $arr[] = $_REQUEST['data']; можно сразу писать Class::preExec($sql, [$_REQUEST['data']], $db);
2. Статическая функция, которая принимает параметром соединение с БД выглядит как-то странно. Откуда-то ведь соединение берется? Почему бы данную функцию не добавить туда, откуда берется соединение, чтобы оно уже присутствало в объекте и его не нудно было передавать?

Answer 1

[asd111]

PDO защищает от sql injection. Вам еще понадобится выводить данные пользователям так чтобы не было XSS. Ещё вам нужна будет защита CSRF. И ещё по мелочи.
В общем берите laravel или symfony и не мучайтесь.

Answer 2

[ThunderCat]

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

Answer 3

[McBernar]

Путаете теплое с мягким.
Валидация форм и защита от инъекций — это совершенно разные задачи.

Для защиты достаточно PDO.

Comments

[FanatPHP]

Самый адекватный ответ.

Answer 4

[Андрей К]

Вам уже правильно написали, но без разъяснений, что пользовательский ввод нужно валидировать не только на вход, но и на выход.

Например, если человек напишет и это будет отправляться на доступную страницу - это вас неприятно удивит.

И много других приятных сюрпризов может быть.

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

Мораль, не нужно изобретать велосипед на таком уровне знаний, берите фреймворк и в путь. Это когда Вы уже все знаете и понимаете почему решение из Вашего фреймворка Вас не устраивает, вот тогда нужно делать велосипед.