Здравствуйте, Sinclair, Вы писали:

A>>Может выйти за пределы сервера базы в систему: работать с файлами, запускать процессы с правами системного пользователя, под которым работает субд.
S>Совершенно не факт, что СУБД работает под какими-то более широкими правами, чем тот же самый апп-сервер.

Здесь опять-таки вопрос разграниечения доступа. Под каким системным пользователем работает процесс, в котром иполняется процедура? Наверняка под каким-то пользователем, который имеет расширенные права с возможностью чтения всех data-файлов. В сервере же приложений разные модули могут работать под разными пользователями и даже на разных машинах.

S>Ну да, конечно же там работает песочница — как и везде. Но ещё раз: что такого ценного вы видите на сервере СУБД, что более ценно, чем сама база данных?
S>Там самый главный файл — это собственно БД, только она денег и стоит. Человек, который может задеплоить произвольный код в сервер приложений, прекрасно дампнет вашу базу конкурентам безо всякой кодогенерации.

Баз может быть несколько, и не ко всем базам из субд будет доступ, и при правильном подходе бизнес-программист в базе далеко не админ.

S>Основной риск — это code injection, когда злоумышленником выступает не программист, а внешний пользователь. Ну так опять же — drop table customers он вам заинжектит и через обычный DML, даже если прав на динамическое развёртывание кода у него нету.

Это другое, здесь именно риск получения доступа на уровне операционной системы. Я, конечно, понимаю всякие системы прав, песочницы, домены, но настройка сильно усложяется, и можно, не заметив, выдать слишком много прав.

Вот, например, просит приложение выдать ему:

dbms_java.grant_permission(user_name, 'SYS:java.lang.reflect.ReflectPermission', 'suppressAccessChecks', '');

И как админу на это реагировать?