раскрыть ветку (1)
И обычная инъекция как аллюзия на sql-инъекцию, самым популярным примером которой обычно является выполнение команды "drop table"
показать ответы
раскрыть ветку (1)
Дело не в том, что было до создания SQL, а в том, для чего язык создавался:
However, there is also a large class of users who, while they are not computer specialists, would be willing to learn to interact with a computer in a reasonably high-level, non-procedural query language. Examples of such users are accountants, engineers, architects, and urban planners. It is for this class of users that SEQUEL is intended
из статьи SEQUEL: A structured English query language за авторством Donald D. Chamberlin, Raymond F. Boyce
показать ответы
У БД нет никаких API библиотек, нет никаких методов и нет никаких специальными параметров. Взаимодействие с БД осуществляется набором dml, ddl комманд, различными админ командами и написанием кода на встроенном в бд языке программирования.
Это происходит не на пользовательском уровне. Пользователь работает с фронтом, фронт ходит через бэк, а бэк работает с БД через биндинг - либу, которая занимается безоасным формированием DDL и DML в ответ на вызовы методов и функций. Большая ошибка писать собственный велосипед для экранированиия параметров. Всегда есть огромное количество спецаильных библиотек для работы с БД из любого языка программирования.
SQL-инъекции пресекаются именно на этом этапе.
Если вам встречались только проекты где всего этого достаточно, то это не значит что сложных проектов нет.
Мне встречались легаси-проекты. в которых тысяча таблиц и полторы тысячи хранимок. Часть бизнес логики засунут в эти хранимки, а часть сделана в толстом клиенте. Это был ужас и кошмар. Если есть возможность не пихать логику в базу, нужно так и делать. Нужно по возможности отделать данные от логики, иначе с этим работать будет очень некомфортно.
Да, безусловно есть специальные случаи и исключения. Мне приходилось писать гиганстские SQL-запросы на несколько экранов с кучей подзапросов и всё это снабжать планами, потому что автоматически индексы выбирались не эффективно. Обычно такое было связано со сложной аналитикой или одноразовой подготовокой данных в рамках больших миграций.
Я в ваши оракловские сани со своим уставом лезть не буду, коллега. ораклом не работал, но после файрбёрда и посгреса, после того как глубоко потрогал монгу, после вот этого всего я для себя четко уяснил, что данные и код смешивать следует минимально.
Я не утверждал никогда. что ORM-панацея, просто нужно стараться избегать оверинженеринга. Иногда гораздо лучше и эффективнее себя показывает NoSQL подход.
Это как раз таки означает что в проекте опытный архитектор который уже видел к чему может привести ОРМ. И понял что ОРМ не дает и половины функционала самой БД. И понял что источник гуано в лице ОРМ в его проекте ему не нужен и выделил специального человека.
"Может привести", а может и не привести. Всякому инструменту свое применение. Так-то и микроскопом можно гвозди забивать, а молотком зубы лечить, но специальные инструменты ко всему применять правильнее. А такой категоричный подход меня малость пугает. Вот, оказывается, все беды из-за ORM, а мужики-то не знают...
Ничего плохого в ORM нет, если умеешь его использовать и понимаешь области его применения. Тем более ничто не мешает смешивать подходы и что-то извлекать без всякого ORM.
Вы случайно не ORM называете API к базе данных?
Нет.
И что ОРМ вообще не является частью БД?
Да блин, да откуда у вас такие помыслы вообще, сударь? Какая, блин ОРМ часть БД?=0
Или вы думаете что без ОРМ к данным из базы никак не подобраться?
Пипец... ОРМ - это просто одна из возможных прослоек, чтобы не иметь дела с запросами в простых случаях, а иметь дело с разу с модельными объектами предметной области.
Если у вас есть несколько слоёв. то между слоями есть API. Функции с сигнатурами. которые следует вызывать, чтобы работать с БД - это тоже API. Протокол и датаграммы общения с базой через сокет - это тоже API, но низкоуровневое.
Модели ОРМ тоже имеют своё API, чтобы с ними взаимодействовать.
Слои.
Так это устроено. Разные люди пишут разный код и чтобы этот код разных людей мог обращаться к другому коду других людей есть API.
SQL-инъекции возникают, когда программист вместо правильного использования API-библиотеки биндинга вызывает SQL напрямую строковой конкатенацией подставляя в него параметры так, что этот SQL ожет поломаться из-за кустарно-велосипедного экранирования и злонамеренно составленных входных данных при атаке.
Правильно - не давать неопытным разработчикам писать свои велосипеды в таких ответственных и непрозрачных местах, как обмен данными между базой и бизнес-логикой. Нужно проверять, чтобы разработчики бэка реализуя бизнес логику ПРАВИЛЬНО использовали готовые КАЧЕСТВЕННЫЕ библиотеки биндинга к БД, а не сооружали опасные SQL-запросы из данных пользовтаеля вручную на коленке.
раскрыть ветку (1)
Вы так рассуждаете, как будто реализация логики работы с данными на уровне бэк енда - это априори правильное и богоугодное дело, а все остальное - костыли и велосипед. Однако для меня это просто мечтания отдельных личностей, которые разбились о суровую реальность. Я уже вам приводил примеры, когда этой логике нечего делать в бэк-енде. Но вы толи игнорируете эти примеры, то ли ожидаете что кто то будет разделять логику работы с данными на уместную и неуместную в бэке, на простую и посложнее и эта логика будет лежать и в бэке и в базе. И тогда уже никто не сможет сходу сказать где лежит искомая реализация и надо будет искать во всех возможных местах.
"Может привести", а может и не привести. Всякому инструменту свое применение. Так-то и микроскопом можно гвозди забивать, а молотком зубы лечить, но специальные инструменты ко всему применять правильнее. А такой категоричный подход меня малость пугает.
А вы перестаньте навешивать ярлыки на хранимки и такой подход перестанет пугать. То что вам было с ними тяжело ни о чем не говорит. Вернее ничего не говорит о хранимках.
Вот, оказывается, все беды из-за ORM, а мужики-то не знают...Может ваши мужики и не знают, а вот эти вот знают:
(см видео внизу)
И куча других мужиков с которыми я общался лично тоже знают. И все говорят что за пределами CRUD операций ORM усложняется в разы. И начинаются костыли в виде prepareStatement (в лучшем, а в худшем монструозное использование ORM от которого все вешаются). Так что говорите только за себя, а не за всех мужиков.
Да блин, да откуда у вас такие помыслы вообще, сударь? Какая, блин ОРМ часть БД?=0Да потому что я уже вторые сутки пытаюсь понять что вы называете API и через какой это API лично я работаю с БД и почему я не вызываю никаких методов и не понимаю как правильно и как неправильно в эти невидимые методы передавать параметры. И уже отчаялся это понять. Так что не начинайте плиз по второму кругу. Пусть у вас всё будет через АПИ, а у меня не всё.
P.S. Сорри, хз как кошерно вставить видео. Не обессудьте
YouTube●50:53
YouTube●58:12
Нет. всё начиналось с того, что возможность SQL-инъекций - это исключительно ответственность бэкендера и правильного использования библиотек доступа к БД. Например передача параметров в звпросах конкатенацией SQL вместо использзования специальных параметров в API библиотеки.
А что вы там так абстрактно и загадочно пишете про "правильное извлечение данных из БД" я даже разбираться не хочу. Какая разница? Опять скажете "косоязычно" цепляюсь к словам, а мы ж тут не филологические прения устраиваем. косноязычность нас тут волновать не должна.
Срезюмирую. Если в проекте отдельный человек (а почему-то не бэкендер) занимается "разработкой базы данных" (хотя что там разрабатывать, обычно испольльзуется ORM и БД описывается декларативно кодом моделей в бэке), и этот человек наделал хранимок, уязвимых для SQL-инъекций (то есть злоупотребил выполнением SQL, полученного путём сборки сырых строк из входных данных), то в проекте уже большие проблемы с архитектурой.
Это всё, что я хотел сказать. С чем вы тут хотели поспорить?
раскрыть ветку (1)
С чем вы тут хотели поспорить?
С тремя вещами:
Например передача параметров в звпросах конкатенацией SQL вместо использзования специальных параметров в API библиотеки.
У БД нет никаких API библиотек, нет никаких методов и нет никаких специальными параметров. Взаимодействие с БД осуществляется набором dml, ddl комманд, различными админ командами и написанием кода на встроенном в бд языке программирования. Это и есть тот интерфейс работы с бд, которая бд предоставляет. (Есть еще низкоуровненвые вещи наподобие Oracle Call Interface, это я готов назвать API, но отношение к sql-запросам он имеет весьма опосредованное).
Если вы с этим не согласны, то приведите тогда пример метода, после вызова которого Оракл вернет вам курсор запроса.
(хотя что там разрабатывать, обычно испольльзуется ORM и БД описывается декларативно кодом моделей в бэке)
Обычно - это в простеньких проектах которые никогда не столкнуться со сложной логикой работы с данными, от которых все эти ОРМ начинают творить лютую дичь. Я уже привел вам кучу примеров логики, которая выполняется только на уровне БД и в которой ОРМ вообще не при делах. Вы думаете кто то научил компьютер программировать и теперь можно просто говорить ему что нужно, а он сам накодит sql-запрос? Это тоже самое что думать что конструктор сайтов заменит веб-программирование. Если вам встречались только проекты где всего этого достаточно, то это не значит что сложных проектов нет. Там где то есть комментарий человека, который считал что ОРМ на все хватает, посмотрите сколько с ним согласны, а сколько нет.
Если в проекте отдельный человек и этот человек наделал хранимок, уязвимых для SQL-инъекций (то есть злоупотребил выполнением SQL, полученного путём сборки сырых строк из входных данных), то в проекте уже большие проблемы с архитектурой.Это как раз таки означает что в проекте опытный архитектор который уже видел к чему может привести ОРМ. И понял что ОРМ не дает и половины функционала самой БД. И понял что источник гуано в лице ОРМ в его проекте ему не нужен и выделил специального человека. Который уже мог написать говнокод, но это проблемы уже не архитектора. Вот к таким людям я и адресовал шутку.
Вы случайно не ORM называете API к базе данных? Тогда есть 4-й вопрос.
АПИ у БД, конечно же, есть у любой. Для чего бы кому-то пригодилась база данных без интерфейса?
Вы же понимаете что кроме API-ORM у базы данных остается достаточно интерфейсов? И что ОРМ вообще не является частью БД? Или вы думаете что без ОРМ к данным из базы никак не подобраться?
показать ответы
Ок, фронтендера я помянул в сердцах. Но в посте-то речь про SQL-инъекции. Причем тут логика внутри СУБД?
Делать так, чтобы SQL-инъекции были невозможными - это задача бэкенд-разработчика. АПИ у БД, конечно же, есть у любой. Для чего бы кому-то пригодилась база данных без интерфейса? На всякий случай напомню, что интерфейс - это не обязательно что-то графическое. В данном случае API - это программный интерфейс и работать он может через вызовы функций динамической библиотеке или через промежуточный биндинг к тому или иному языку. В конечном итоге почти любая современная БД обычно предосталяет API через TCP-соединение.
Но давайте всё же подумаем какие такие SQL-инъекции могут оказаться на совести разработчика БД... Вообще тот еще вопрос что разрабатывает этот разработчик в отрыве от бэкенда. Струкутуру? Связи? Индексы? Ок. Засовывает бизнес логику в хранимые процедуры (такая себе идея, конечно, особенно если это все живёт вне системы контроля версий)?
Короче, если пользователи могут подать куда-то на вход данные, которые поломают нормальную работу SQL сформировав недопустимый запрос, то это проблема бэкенд разработчика, который неправильно работает с API БД или техлида проекта, который допустил прямой доступ пользователей к выполнению запросов в БД, а разработчик хранимок наваял там такой логики, что без должного экранирования наконкатенировал там запросов, способных при должной инъекции поломать всё.
раскрыть ветку (1)
Что живет вне системы контроля версий, а что внутри, вообще не должно влиять на архитектуру систему, это сугубо проблемы разрабов и и удобство их работы. Писать говно код потому что так удобнее, как раз таки и есть так себе идея. Код из хранимок вполне нормально хранится в системах контроля версий, потому что представляет собой обычный текст.
Ничто лучше субд не справляется с работой с данными, поэтому всю логику работы с данными как раз таки должно хранить на уровне субд, если эта логика обещает быть сколько-нибудь сложной (а она почти всегда становится такой, когда у заказчика возникает больше хотелок). А ведь есть еще процессы, который должны запускаться регулярно по ночам (джобы, короче говоря), их тоже выносить из хранимок и хранить то что работает только в бд за пределами этой самой бд? Как тебе такая идея? А как тебе идея хранить в бэк енде функции, которые используются в фильтрах запроса? А если они используются в function-based индексах? А если функция кроме как в запросах больше нигде не используются и ей не плохо нацепить pragma udf, такую тоже хранить на бэк енде?
И именно разработкой этих хранимок и занимается разработчик БД. И я никогда не называю хранимки как API к базе, так как они являются таким же кодом проекта как и все остальное и оно не поставляется вместе с субд. И эти хранимки сложно использовать коряво, т.к. ты просто передаешь параметры и получаешь результаты в виде курсоров или готовых значений (или кодов ошибок). И если разработчик хранимок "наваял там такой логики, что без должного экранирования наконкатенировал там запросов, способных при должной инъекции поломать всё" то это проблема разработчика хранимок, а не бэк-ендера, который эту хранимку тупо вызвал.
показать ответы
ох...
API (программный интерфейс приложения, интерфейс прикладного программирования) (англ. application programming interface, API [эй-пи-ай][1]) — описание способов (набор классов, процедур, функций, структур или констант), которыми одна компьютерная программа может взаимодействовать с другой программой. Обычно входит в описание какого-либо интернет-протокола (например, RFC[2]), программного каркаса (фреймворка)[3] или стандарта вызовов функций операционной системы[4]. Часто реализуется отдельной программной библиотекой или сервисом операционной системы. Используется программистами при написании всевозможных приложений.
Кошмар.
раскрыть ветку (1)
И? Чем из всего этого является компилятор или парсер?
Впрочем, можешь называть это все API, мне не жалко. Важно чтоб ты сам понимал, как в эту твою парадигму ложится твоя же фраза про "правильное использование API". С твоего позволения фразу "написание говнокода" я лично никогда не буду приравнивать к фразе "неправильное использование API". А то выглядит косоязычно. И притянуто на глобус.
Главное во всем этом то, что у тебя не осталось вопроса, почему бэкендеры обычно не при делах, когда дело касается правильного извлечения данных из БД. А именно с этого все и началось.
показать ответы
Добавь лучше к перлам своё изречение, будто у БД не бвывает API и мысль, будто бы хранимки - это API. Тут не цепляние уже
раскрыть ветку (1)
Мысль, будто хранимки - это API пришла мне после прочтений твоих высказываний. Без твоего помощи мне бы это в голову не пришло. Мыслей наподобие той, что компилятор pl/sql который выполняет команду create or replace package - это оказывается API. И парсер sql-запроса, это тоже API. Почитай что ли вначале что такое API, а потом уже заявляй что взаимодействие с базой происходит через него. И вообще видимо если что то с чем взаимодейтсвует, то обязательно через API.
А потом еще можно будет обсудить перлы о том, stored procedure из БД должна храниться (stored) вовсе не в бд, а в vcs. И должны появляться в базе после деплоя, и вообще называться видимо deployed procedure.
показать ответы
Ух... че-то я шевельнул...
Что живет вне системы контроля версий, а что внутри, вообще не должно влиять на архитектуру систему, это сугубо проблемы разрабов и и удобство их работыНа архитектуру влиять не должно - это да, но не хранить ВЕСЬ код в системе контроля версий того или иного проекта - это дилетантство.
Писать говно код потому что так удобнее, как раз таки и есть так себе идеяПричем тут говнокод? Говнокод можно написать и хранить где угодно. Речь не об этом. Есть еще и говноархитектура.
Код из хранимок вполне нормально хранится в системах контроля версий, потому что представляет собой обычный текст.Отлично. Я рад, что вы это понимаете. А-то есть чудаки мудрые, которые держат и редактируют код хранимок исключительно и напрямую в БД, а не накатывают в рамках миграций на чистую базу.
Ничто лучше субд не справляется с работой с данными, поэтому всю логику работы с данными как раз таки должно хранить на уровне субд, если эта логика обещает быть сколько-нибудь сложной (а она почти всегда становится такой, когда у заказчика возникает больше хотелок).СТОП, ЧТО!!!
В смысле хранить логику в БД?! БД - это база данных, там данные нужно хранить. Ещё там приходится хранить структуру (таблицы, связи, индексы), некоторые складывают в БД хранимые процедуры. Первоисточник их лежит в коде и код при деплое умеет их накатывать вместе со структурой с помощью миграций. Если у вас в БД лежит код хранимок, которого нет в системе контроля версий и в миграциях, то этот код временный для экспериментов или какой-то аварийной аналитики. Иначе вы рискуете разъехаться логикой с бэкендом. Разработчики-то сидят на разных ветках и версиях, а еще есть CI\CD, интеграционные тесты и прочее. Они могут работать со стейджинговыми БД, бэкапами и срезами.
Можно какую-то логику помещать в БД, но помещаться оно туда должно в рамках какого-то процесса деплоя и с отслеживанием версий.
хранить то что работает только в бд за пределами этой самой бд? Как тебе такая идея?Отличная идея! Хранить код нужно в системе контроля версий. Размещаться в точке его выполнения код должен в рамках процесса деплоя.
я никогда не называю хранимки как API к базе, так как они являются таким же кодом проекта как и все остальное и оно не поставляется вместе с субдЯ тоже не называл ваши хранимки API. API - это интерфейс выполнения SQL-запросов к БД и получения результатов.
И если разработчик хранимок "наваял там такой логики, что без должного экранирования наконкатенировал там запросов, способных при должной инъекции поломать всё" то это проблема разработчика хранимок, а не бэк-ендера, который эту хранимку тупо вызвал.Это исключительно проблема техлида, который не провел ревью и не надавал по шапке за такие уязвимости. Передавать паремтры в любые запросы к БД нужно либо через специальные механизмы передачи параметров в рамках API, либо очень тщательно очищая и валидируя их на бэке.
раскрыть ветку (1)
Спасибо за комментарии, которые в основном правда представляют собой цепляние к словам.
Но что сказать то всем этим хотел? Что кроме говнокода есть говноархитектура? Ну если детализировать, то да.
Прицепился к слову "хранить", и все сообщение доказывал что хранить нужно в системе контроля версий. Как будто с этим кто то спорил. Рассказывал про правильный деплой, как он работает и прочее. Но как это все отвечает на вопрос "кто наговнокодил так, что возникла возможность sql-инъекций"? Ведь суть разговора, напомню, была именно в этом.
P.S. API к БД как "интерфейс выполнения sql-запросов" я добавлю в свою коллекцию перлов, с твоего позволения.
показать ответы
В смысле не бэкендеров? А чьё же? Фронтендеров? Или бэку SQL специальные люди писать должны для взаимодействия с БД? Вот это сегрегация!
Если у тебя в проекте такая ДЫРИЩА в бэке, что туда пользователь может просунуть свой... SQL-запрос, то тут не DBA виноват, а косорукий программист, который не понимает, что такое валидация параметров, как правильно экранировать входные данные в SQL и как правильно пользоваться API используемой БД.
раскрыть ветку (1)
Как-то у тебя все так намешано, что я уже пожалел что взялся отвечать. Приплел зачем то ДБА, хотя они тут вообще не при чем. Почему то предположил что должны писать фронтендеры, хотя в посте прямо указано кто это должен делать (да и в твоем первом сообщении тоже). Упомянули какие то АПИ к базам данных, которого в некоторых случаях просто не существует. У СУБД Оракл такого точно нет. И что не так в специальных людях для написания логики работы с данными, я так и не понял. Для меня слово "сегрегация" не ругательное. Или разделение на бек и фронтенд - тоже зло?
показать ответы
Вообще-то SQL-ъекции - это как раз про криворукость бэкендеров. Причем тут разработчики БД?
раскрыть ветку (1)
При том, что это не бэкендеров дело писать запросы и хранимки с ними. Только плиз, не надо писать про орм.
показать ответы
IT-юмор
7.1K пост53.2K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору