Как самописно защитить строку sql без знания кодировки БД?

Question

[cheremsha11]

Вот здесь приведен пример https://www.php.net/manual/ru/pdo.quote.php#122967 того, как собираюсь экранировать все строковые переменные, которые включаются в запрос. Дополнительно их буду заключать в одинарные кавычки. ORM и PDO не нужно, слишком проект простой и должен быть быстрым. Защитит ли это от всех иньекций, в той же степени как с mysqli_escape_string, например, или тем же PDO::quote (... ) ?

Comments

[Влад Хеллсайт]

А в каком месте, PDO -- это медленно и сложно?

[Stalker_RED]

Владлен Хеллсайт, PDO в некоторых случаях прям спамит prepare запросами создавая некоторый оверхед.
С другой стороны, если человек уже парится за этот оверхед, но еще не умеет экранировть - лучше бежать подальше)

[cheremsha11]

Использование PDO us простой str_replace() склоняет больше во вторую сторону. И по скорости и по простоте. Мне хочется уточнить только, хорошая ли это защита (пример был приведен по ссылке).

[sim3x]

cheremsha11,

Хм
А у вас есть за плечами 10+ лет в пхп разработке и инфобезе, чтоб написать нормальную защиту на базе реплейса?
Ого
Круто

Тогда зачем задаете тут вопрос
Пишите

Думаю месяца два-три уйдет на сбор тесткейсов по багтрекерам
А там за месяц и код напишете
В идеальном случае

Удачи и не забудьте похвалиться ссылкой на гитхаб

[cheremsha11]

Как понимаю здесь

array("\\", "\x00", "\n", "\r", "'", '"', "\x1a")

перечислены все спецсимволы sql, за исключением тех, что используются в LIKE между %%. Насколько актуально при этом знать кодировку БД?

[Евгений Ромашкан]

cheremsha11, Писать с PDO выйдет быстрее.

[Vitsliputsli]

ORM и PDO не нужно, слишком проект простой и должен быть быстрым

А почему вы решили что ORM и PDO, это медленно? Вернее, почему вы решили, что написанная вами обертка для работы с БД будет работать быстрее? Я уже не говорю о безопасности.
Ну да бог с ними, с ORM и PDO, будем работать с специализированным драйвером, но почему нельзя воспользоваться встроенной системой байндинга? Забудем о безопасности, но ведь при байндинге, запрос подготавливается и на стороне СУБД кешируется план, что опять же влияет на скорость.
В общем, для простых проектов есть простые и быстрые решения.

[cheremsha11]

Vitsliputsli, это не мной написанная обёртка, та что по ссылке. У меня нет 10-летнего опыта разработки на PHP, этого и не нужно, чтобы написать прямо сейчас простое приложение, использующее sql. Вот например Laravel использует свою ORM, внимание - там самописная очистка или надстройка над PDO или иным встроенным в PHP решением? Не уверен, что проекты на Гитхаб, которые здесь рекламируют, дают какие-то гарантии. В любом случае за строчку на str_replace я ещё как то могу разделить ответственность перед заказчиком, а вот подгрузка сторонних библиотек по лицензии "прими как есть"... Совсем не против библиотек, но плодить сущности без необходимости тоже не хочется.
Вы вообще видели эти заморочки с выносом плейсхолдеров в pdo, а in ( ... )? Пропадает всякая читаемость.

PDO в некоторых случаях прям спамит prepare запросами создавая некоторый оверхед.

и не всё там так гладко.

[cheremsha11]

Подробнее про pdo и ссылку на PDO::quote что я привел в начальном сообщении. Оттуда следует, что некоторые драйверы не поддерживают экранирование, но кто нибудь из пользующихся pdo проверяет возвращаемый ответ PDO::quote на корректность?Ок, странная логика PDO::quote вернуть false в строку, которая исказит запрос и возможно и вызовет иньекцию сама по себе. К тому же как написано в документации

Возвращает экранированную строку, которую теоретически безопасно использовать в теле SQL запроса.

. Очень обнадеживает.

[Vitsliputsli]

cheremsha11, вместо всего этого бесполезного переживания по поводу PDO::quote, прочитайте ещё раз описание. А там сказано: "Если вы используете эту функцию для построения SQL запросов, настоятельно рекомендуется пользоваться методом PDO::prepare() для подготовки запроса с псевдопеременными вместо использования PDO::quote() для вставки данных введенных пользователем в SQL запрос. ". Такие настоятельные рекомендации пишутся специально для тех, кто выискивает проблемы там, где их нет. Используйте рекомендованные инструменты. Нет ничего идеального, и PDO действительно имеет проблемы, но не те, что вы обозначили.

Вы вообще видели эти заморочки с выносом плейсхолдеров в pdo, а in ( ... )? Пропадает всякая читаемость.

Нет никаких заморочек, а читаемость выше, чем у специализированных драйверов. Но после PDO::quote не удивлюсь, что и здесь вы сделали по-своему, отсюда и проблемы.

PDO в некоторых случаях прям спамит prepare запросами создавая некоторый оверхед

Расскажите, пожалуйста, поподробнее.

[Vitsliputsli]

В любом случае за строчку на str_replace я ещё как то могу разделить ответственность перед заказчиком, а вот подгрузка сторонних библиотек по лицензии "прими как есть"...

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

[cheremsha11]

Vitsliputsli, ну так я и хочу воспользоваться готовым решением, дал на него ссылку в конце концов в самом начале. Не знаю, как у вас принято, но прежде чем подключить библиотеку с гитхаба к проекту мне необходимо пробежаться как минимум глазами по коду, чтобы не было какого нибудь криминала. На это уходит время, плюс, если сравнивать str_replace против библиотеки, преимущество налицо.

А серверы у вас крутятся на самописной ОС? А процессоры к серверам тоже сами собираете?

Мне кажется вы перегибаете. У меня есть известная мне бд, кодировка utf-8, запросы экранируются ( проверил на простых попытках иньекций) вопрос лишь в том, корректно ли готовое решение по ссылке, которую привёл.

[Vitsliputsli]

cheremsha11, пользуйтесь, кто ж запрещает, на вопрос ваш, как следует действовать, ответили, но если хочется переписать базисный функционал самому - ваше право. И вы также правы, если сравнивать попытки с помощью str_replace выполить то, что делает специализированная функция php (да еще и при поддержке СУБД), то преимущество налицо. Заметьте, речь не идет ни про github, ни про PDO.
Я тоже не знаю как принято у вас, но хотел бы увидеть того заказчика, который платит разработчику за переписывание функционала php, вместо работы над проектом.

[cheremsha11]

Vitsliputsli, если вы про mysqli_escape_string ( , pg_escape_string и тд.) то это уже используется, но не устраивает. Использование того базового функционала, который используется у меня, вместо вашего подразумеваемого "функционала php", позволило мне переключить все сайты на php7 просто установив новую версию php на сервере. За экономию времени и рационализм мне и платят в том числе. А если mysqli_escape_string упразднят, как упразднили mysql_escape_string (из-за его опасности)? Вот str_replace врятли это коснется. Здесь скорее дело в конкретной ситуации и в конкретных решениях.

[cheremsha11]

На мой вопрос никто даже и не пытался ответить. Спасибо за советы, как вы бы сделали на моём месте. Но это все решает одну проблему, добавляя другие. Понимаю, что без проблем в коде не будет столько работы программистам, но... Здесь вообще есть профи?

[Vitsliputsli]

cheremsha11, на ваш вопрос вполне ответили, не так как вам хочется, но ответили. И нет, я писал про подготовленные запросы, об этом же вам писали и создатели php, т.к. это основополагающий метод предотвращения инъекций, да и оптимизации работы.
Вы и на php11 перейдете без проблем, если не будете пользоваться функционалом php, так что странный аргумент.

За экономию времени и рационализм мне и платят в том числе

А можете рассказать, как это происходит, как оценивают ваш рационализм и экономию времени? К примеру, вы неделю занимаетесь исследованием как бы написать свой механизм бандинга переменных в запросе вместо стандартного, сколько здесь можно насчитать экономии времени и рационализма?

[cheremsha11]

Vitsliputsli, да именно так, неделю прикидываю, как написать, чтобы работало 10 лет без сбоев, а потом за пару дней пишу функционал. Да и по ссылке утверждается, что приведенный способ в 50 раз быстрее обычного, кстати говоря и по факту примерно так и получается. Платят за то, что остается время на несколько проектов без бесконечного переписывания под новведения.

С каких это пор PDO стал основополагающим в PHP? По истории языка это просто модное новведение и неизвестно, закрепится ли или нет. Основополагающим должен был быть mysql_escape_string, но создатели php c ним накосячили.

[Vitsliputsli]

cheremsha11, я спрашивал про оценку того, кто платит за вашу работу, как выглядит статья расходов "за экономию времени и рационализм"?

С каких это пор PDO стал основополагающим в PHP?

Я такого не писал, подготовленными запросами вы можете пользоваться хоть в PDO, хоть в специализированном драйвере. Вам следует более детально ознакомиться с работой с СУБД. Какова сложность ваших работающих по 10 лет сайтов, если вы только сейчас начали изучать работу с СУБД?
И да, хотите или нет, PDO стал основным драйвером. Про отсутствующие функции типа mysql_escape_string даже не говорю. Поэтому уже не понятно, что для вас обычное, хотя упирать на скорость сам по себе слабый аргумент, продолжая в таком духе, вам следует отказаться и от ключей, и от индексов, и от транзакций в СУБД.

[cheremsha11]

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

остается время на несколько проектов без бесконечного переписывания под новведения

Премировочная плата за сравнительную производительность, если хотите.

Всё, что я сделал, это выложил ссылку на функционал, утвердил его актуальность и попытался наладить продуктивный спор. Дискуссия зашла в "да ты кто такой, да надо лучше изучать матчасть, используй pdo и малоизвестные ORM, а что там конкретно экранируется, да при каких условиях, знать не нужно".

[Vitsliputsli]

cheremsha11, не, не так, пишу в 5 раз, я писал о подготовленных запросах, используете ли вы PDO или ORM здесь не при чем. И да, прочитайте, наконец, и перестаньте спорить не с моими, а выдуманными аргументами. Что и как экранируется вы действительно не знаете, т.к. отказываетесь что-либо изучать, да и просто слышать. Вам кажется, что можно тупо поменять символы, но все несколько сложнее, но идти дальше вам лень.

неделю прикидываю, как написать, чтобы работало 10 лет без сбоев, а потом за пару дней пишу функционал.

Простите, я посчитал, что это на чем то основывающиеся утверждение, тогда уж пишите "и надеюсь, будет работать 10 лет"...

[cheremsha11]

Vitsliputsli, аргументированный ответ или хотя бы какие-то намёки о ваших знаниях в этой области, не прослеживаются.

[Vitsliputsli]

cheremsha11, еще бы, зачем намеки, когда пишешь прямым текстом, могу в 6 раз написать - подготовленные запросы, полная защита от sql-инъекций + оптимизация работы с БД за счет кеширования плана. Самое примечательное, что речь не о моих знаниях совершенно, а банально о технологии. Так будет ли с вашей стороны аргументация или опять предпочтете не замечать?

[cheremsha11]

К понятию "аргументация". Вы используете тезисы, а не аргументы к ним. Это разные вещи. С моей стороны был конкретный вопрос с примером кода (не моего), если вы по нему не можете ни слова ответить конкретно - вот здесь пройдет иньекция, например, а приводите обобщённые фразы, которым можно попугая научить отвечать на все вопросы о БД. Если бы вы шесть раз повторили, то я бы так и подумал.