Всем привет. Такой вот момент. Использую PDO и и БД MySQL. Насколько понимаю, защита от SQL-инъекций в этом случае , по умолчанию, это просто экранирование от управляющих символов в подготовленные запросе, а не некоторые внутренние механизмы БД. В связи с этим, имеет смысл выставлять PDO::ATTR_EMULATE_PREPARES в false или всё неправильно понял и даже не стоит заморачиваться этим вопросом?
Если используешь подготовленные запросы через prepare то SQL-инъекции уже не пройдут, потому что происходит экранирование. Другое дело что легко пройдут различные JS-инъекции типа XSS или атака CSRF. Для XSS нужно фильтровать входящие данные на XSS атрибуты, а для CSRF нужно передавать токен и сравнивать его с токеном на сервере.
@Александр101, мне это так объясняли: выставляешь PDO::ATTR_EMULATE_PREPARES в false, когда хочешь в явном виде делать неподготовленные и подготовленные запросы (некоторых эмуляция раздражает). Т.е. не надо пытаться выставлять или не выставлять этот флаг в зависимости от запроса и потом делать только «подготовленные» запросы.
Только делать это с умом, если я в форуме в сообщении пишу <script>alert(1);</script>, оно потом так и будет отображаться в сообщении.
Естественно с умом. Иначе это JS все пролезет к примеру с комментариями. Проблемы с JS-атаками решает эта замена для всех ВХОДЯЩИХ данных: PHP: $find = ["'", "script", "/.", "./"]; $replace = ["‘", "!s-c-r-i-p-t!", "!/.!", "!./!"]; Мне пришлось перелопатить более 1000 основных типов JS атак по базам хакеров, чтобы протестировать и подобрать эти простые замены, после которых все эти типы атак удалось прикрыть. На самом деле всего 4 замены и все прекрасно теперь решается. В итоге JS код превращается в не рабочий экранированный вариант, и остается в тексте не нанося вреда. При этом благодаря заменам с восклицательными знаками его сразу видно к примеру в комментариях. <script>alert(1);</script> превращается в <!s-c-r-i-p-t!>alert(1);</!s-c-r-i-p-t!> не нанося вреда, но его прекрасно видно модератору к примеру. Да, если к примеру эти символы будут нужны в тексте, то в принципе в итоге все равно становится понятно о чем речь. К примеру если слово script будет нужно в комментарии, то оно заменится на читаемый безопасный вариант.
@musicman3, при выдаче нужно приводить к верному формату, а не вот это вот всё. Естественно, что если на входе ожидается [0-9][a-z][A-Z], валидировать на входе и пинать сразу при попытке ввода фигни.
Мы говорим про ВХОДЯЩИЕ данные а не при выводе. Вывод всегда можно отфильтровать и заменить по указанным меткам как заблагорассудится, хоть с подсветкой
В общем пришёл к такому выводу. Полноценный подготовленный запрос, увеличивает затраты на вычисления. При определённых условиях, в разы. И усложняет формирование запроса к БД, при некой сложной архитектуре этого запроса. Но, гарантирует полное невмешательство в тело запроса. Что может являться в определённых условиях "промышленного применения " критически важным. Эмуляция, быстра, легка, но при определённых условиях, неизбежно вмешается запрос. Но такой запрос, ещё надо умудриться построить и при обычном использовании, он вряд ли понадобится. Соответственно, мне с моими крохотными проектами, это вообще без разницы. И не стоит забивать себе этим голову. Но в целом, знать об этом не помешает. Мало ли, что. А по поводу атак, пропуска всех выходных данных через htmlspecialchars, разве недостаточно?
Не. В маленьких проектах тоже лучше использовать запросы по назначению. Помимо осн. назначения подготовленных запросов (многократного выполнения запросов с разными исх. данными) они используются для получения объемных данных юзера, чтобы не экранировать туеву хучу текста. --- Добавлено --- Использовать только подготовленные запросы – тоже идиотизм.
Думаю, что вопросы оптимизации, когда не используется даже миллионная часть вычислительных мощностей, лишена особого смысла. В целом всё выяснил. И конечно благодарен всем кто уделил время моему вопросу.