Comments 19
Это, действительно, интересное решение. Спасибо за статью!
Думаю, использоваться такое будет, в большинстве случаев, в проектах, которые достались по наследству и на поддержку которых нет времени/средств.
В случае же, если приложение нормально поддерживается и код можно менять, намного предпочтительнее будет правильно обрабатывать входные данные и защищаться от инъекций на уровне своего кода.
Думаю, использоваться такое будет, в большинстве случаев, в проектах, которые достались по наследству и на поддержку которых нет времени/средств.
В случае же, если приложение нормально поддерживается и код можно менять, намного предпочтительнее будет правильно обрабатывать входные данные и защищаться от инъекций на уровне своего кода.
Если обрабатывать все входные данные и передавать их в виде параметров к запросу, то нет никакой нужды в этом инструменте. Исключение, разве что, если кто-то случайно использует динамический запрос.
Но ради этого я бы не стал использовать «прослойку», ведь чем больше шестеренок в механизме — тем больше шансов у него сломаться
Но ради этого я бы не стал использовать «прослойку», ведь чем больше шестеренок в механизме — тем больше шансов у него сломаться
Лично я вместо любого фаервола предпочту использовать хранимки, благо они уже даже в мускуле стандарт
В некоторых хранимых процедурах запрос тоже нужно строить динамически, при помощи конкатенации строк, PREPARE и EXECUTE. И если в такую хранимую процедуру в качестве параметра подается строка, то от SQL-инъекции может спасти только все то же экранирование пользовательских данных на стороне сервера. Так что хранимые процедуры — не панацея.
если в хранимке нужно строить динамический запрос, то 99.99% случаев, что мы неправильно построили архитектуру
Если у вас абсолютно все запросы выполняются через хранимые процедуры (а я так понимаю, что именно такой подход предлагает Scratch), и при этом у вас сложная структура базы данных, — например, EAV-модель, — то вам сложно будет избежать динамического построения запросов.
Например, нужно реализовать поиск по нескольким параметрам, и, если один из параметров подан, то нужно сделать дополнительный JOIN, который в противном случае не нужен и только замедлит запрос. В этом случае без динамического построения запросов не обойтись.
Например, нужно реализовать поиск по нескольким параметрам, и, если один из параметров подан, то нужно сделать дополнительный JOIN, который в противном случае не нужен и только замедлит запрос. В этом случае без динамического построения запросов не обойтись.
Мне приходиться работать с огромнейшими базами данных, порою в несколько терабайт. Еще нигде я не видел, чтобы кто-то использовал динамические запросы. Они во-первых значительно снижают производительность, а во-вторых, если хорошо пересмотреть задачку, то практически все можно построить и без динамических запросов. Те же фильтры — через битовые поля, например
Объем данных в БД никак не связан со структурой базы данных. У вас может быть одна таблица вида id -> value, в которой и будет храниться несколько терабайт данных.
Динамические запросы не снижают производительность, так как являются обычными SQL-запросами. Обычно затраты на построение запроса на несколько порядков меньше, чем затраты на его выполнение в БД.
Вы сами говорите, что практически все запросы можно построить статически. Это правда, но, как я и сказал в своем первом комментарии, для некоторых запросов это бывает необходимо. Например, у нас в проекте используется EAV-модель, и без нее обойтись никак нельзя. Если поможете найти другое решение, да еще и без динамических запросов — заплатим вам много денег ;)
Поэтому, исходя исключительно из своего опыта, я и сказал, что хранимые процедуры нельзя считать панацеей.
Динамические запросы не снижают производительность, так как являются обычными SQL-запросами. Обычно затраты на построение запроса на несколько порядков меньше, чем затраты на его выполнение в БД.
Вы сами говорите, что практически все запросы можно построить статически. Это правда, но, как я и сказал в своем первом комментарии, для некоторых запросов это бывает необходимо. Например, у нас в проекте используется EAV-модель, и без нее обойтись никак нельзя. Если поможете найти другое решение, да еще и без динамических запросов — заплатим вам много денег ;)
Поэтому, исходя исключительно из своего опыта, я и сказал, что хранимые процедуры нельзя считать панацеей.
И даже параметризованные запросы не спасут? ) Просто мне на самом деле сложно представить структуру даже самого сложного проекта где без динамических запросов ну прям никак
Да, это встречается не так часто, и если вы без них можете обойтись, то это просто отлично. Пример, когда обойтись нельзя, — структура, основанная на entity-attribute-value. Я уверен, можно найти и другие примеры.
Вообще говоря, параметризированные запросы спасут в любом случае. Я сейчас вспомнил, что в prepared statements можно подавать параметры отдельным списком, даже из хранимых процедур.
Весьма интересное решение, однако оно ни коим образом не должно исключать фильтрацию запросов на уровне скриптов. А данное решение каким-либо образом фильтрует 2 sql запроса в одном (select…; select ...)?
Эх… И что люди не сделают, лишь бы не пользоваться parametrized/prepared queries…
Согласен, банальная фильтрация и параметризация запроса никогда не
навредит. Но иногда требуется доработать чужой проект. Перелопатить кучу
незнакомого кода может занять не один день. В этом случае greensql может
быть одним из решений. Особненно, если производительность не критична.
Но я в таких случаях пользуюсь сканером find-xss.net — получаю список уязвимостей и уже целенаправленно смотрю код.
навредит. Но иногда требуется доработать чужой проект. Перелопатить кучу
незнакомого кода может занять не один день. В этом случае greensql может
быть одним из решений. Особненно, если производительность не критична.
Но я в таких случаях пользуюсь сканером find-xss.net — получаю список уязвимостей и уже целенаправленно смотрю код.
На графике производительности чётко видно, как падает эффективность GreenSQL при росте конкурирующих запросах. При 15 конкурирующих запросах потеря эффективности 12%.
Для больших проектов это средство не подойдёт.
Для больших проектов это средство не подойдёт.
Sign up to leave a comment.
GreenSQL: Защита SQL-серверов от инъекций