У меня есть процедура, которая будет получать запрос в параметре. Я запускаю входящий запрос внутри процедуры, а инструмент Checkmarx обнаруживает внедрение SQL в my_cursor.
Как мне это решить?
Я пытался ввести функцию dbms_assert.noop, но бесполезно.
`create procedure test(common_query in varchar2)
as
sql_qry varchar2(2000);
Type cursor_type is ref cursor;
my_cursor cursor_type;
begin
sql_qry:= common_query;
open my_cursor for sql_qry;
fetch my_cursor into :name;
close my_cursor ;
end;`
Я пытался ввести функцию dbms_assert.noop, но не разрешил
Я просто пишу это в качестве примера: это обычная программа, несколько процедур/программа Java сформирует запрос на основе логики и пользовательского ввода и отправит этому SP, этот SP будет обрабатывать и выполнять некоторую общую логику, есть ли способ очистить входящий запрос строка для решения проблемы с внедрением SQL
Единственный способ «очистить» целые операторы SQL — это сравнить их со списком предварительно одобренных операторов SQL. Если его нет в списке одобренных операторов, процедура не сможет его запустить. Именно так работают брандмауэры веб-приложений.
Вы решаете эту проблему, не используя динамический SQL.
Не используйте хранимые процедуры только для выполнения запросов. Он не дает никакой ценности, за исключением различных разрешений, что вызывает у вас беспокойство по поводу внедрения SQL. Пусть ваш клиент нормально выполняет запросы без PL/SQL. Тогда стандартную модель разрешений Oracle можно использовать для обеспечения защиты ненадежных пользователей.





SQL-инъекция — это то, что вы делаете. Вы можете либо принять это, либо перепроектировать свой код, но не притворяйтесь, что этого не происходит.
Если вы пишете универсальный инструмент выполнения SQL, например имитацию Oracle SQL Developer или веб-сайт типа dbfiddle.uk, то вам нужно признаться себе, что вы выполняете SQL-инъекцию. Если это так, то ваши проблемы не могут быть решены простым DBMS_ASSERT или «очисткой входных данных вашей базы данных», как подразумевает знаменитый комикс XKCD.
Вам нужно будет тщательно изолировать и защитить пользователя базы данных посредством тщательной проверки привилегий, защиты от DDOS (например, использовать диспетчер ресурсов, чтобы избежать атак с использованием регулярных выражений) и, возможно, других вещей, о которых я не могу придумать. Добавьте в код несколько комментариев «ОПАСНО», чтобы будущие разработчики понимали риск и были в поиске ошибок безопасности. Попросите коллегу проверить код несколько раз.
Прежде чем пойти по этому пути, не пытайтесь попробовать что-нибудь простое, например, «разрешать только операторы, начинающиеся с SELECT». Существует множество хитрых способов внести изменения в оператор SELECT и изменить вашу базу данных. И даже чтение неправильной информации может быть опасным, поэтому вам все равно нужно учитывать привилегии.
Или, по крайней мере, если вы клянетесь всем, что можете доверять всем людям, имеющим доступ к приложению, предназначенному только для внутреннего использования, тщательно все документируйте и размещайте большие предупреждающие знаки, чтобы никто никогда не раскрывал ваш пользовательский интерфейс извне.
Наконец, вы можете изменить CheckMarx, чтобы исключить этот неизбежно несовместимый код. Почти каждое правило безопасности имеет исключение.
Как предположил Билл Карвин, практически все программы используют заранее одобренные операторы SQL, в которые неизвестные значения подключаются как переменные привязки. В менее вероятном, но не очень редком случае, когда вам нужно сделать имя таблицы динамическим, вы можете использовать DBMS_SQL, чтобы проверить этот простой ввод. Или, как предположил Пол У., вам вообще нужна хранимая процедура? (Но не просто внедряйте SQL-инъекцию в интерфейс.) Какой тип обработки и общую логику добавляет ваша хранимая процедура? И можно ли с этим справиться с помощью функции базы данных, такой как представление или виртуальная частная база данных?
Зачем вам нужна такая хранимая процедура? Можно ли изменить ваше приложение, чтобы оно не зависело от такой хранимой процедуры?