Действительно ли я неуязвим для Внедрений SQL, если я использую хранимые процедуры?
Похоже, у вас плохое наименование. Ваш объект местоположения в классе Building называется LocationObject, когда ваш объект внутри JSON называется location.
7 ответов
Нет, Вы не будете абсолютно в безопасности. Как другие упомянули, параметризированные запросы всегда являются способом пойти - неважно, как Вы получаете доступ к базе данных.
Это - что-то вроде городской легенды, что с procs Вы в безопасности. Я думаю причина, люди находятся под этим заблуждением, то, потому что большинство людей предполагает, что Вы назовете procs с параметризированными запросами из Вашего кода. Но если Вы не делаете, если, например, Вы делаете что-то как ниже, Вы являетесь широко открытыми:
SqlCommand cmd = new SqlCommand("exec @myProc " + paramValue, con);
cmd.ExecuteNonQuery();
, поскольку Вы используете нефильтрованное содержание от конечного пользователя. Еще раз все, что они должны сделать, завершить строку ("";), добавьте их опасные команды и бум - Вы политы из шланга.
(Как в стороне, если Вы находитесь в сети, не берут нефильтрованный спам от строки запроса браузера - который делает нелепо легким сделать чрезвычайно плохие вещи к Вашим данным.)
при параметризации запросов Вы находитесь в намного лучшей форме. Однако как другие здесь упомянули, если Ваш proc все еще генерирует динамический SQL и выполняет это, могут все еще быть проблемы.
я должен отметить, что я не anti-proc. Procs может быть очень полезным для решения определенных проблем с доступом к данным. Но procs не "решение серебряной пули Внедрений SQL.
Это зависит, что делают Ваши сохраненные procs. Если они динамично генерируют SQL на основе своих параметров и затем выполняют тот SQL, то Вы все еще уязвимы. Иначе Вы, намного более вероятно, будете в порядке - но я смущаюсь звучать как уверенных 100%!
нет. При построении SQL, который вызывает хранимую процедуру, Вы - все еще цель.
необходимо создавать запросы parametized на стороне клиента.
Вы только неуязвимы для Внедрений SQL consistenly при использовании параметризированных запросов. Вы почти неуязвимые для Внедрений SQL, если Вы используете надлежащий выход везде (но может быть и было, ошибки в стандартных программах выхода, таким образом, это не является столь же надежным как параметры).
, Если Вы называете хранимую процедуру, добавляя аргументы конкатенацией, я могу все еще добавить случайный запрос в конце одного из полей ввода - например, если у Вас есть $username CheckLogin @username =' ВЫЗОВА', @password =' $password', с $ - вещи, представляющие непосредственно связанные переменные, ничто не мешает мне заменить $password для чтения"'; DROP DATABASE; - ".
, Очевидно, при чистке входа заранее это также способствует предотвращению Внедрения SQL, но это может потенциально отфильтровать данные, которые не должны были быть убраны.
Хранимые процедуры не являются гарантией, потому что то, что на самом деле уязвимо, является любым динамическим кодом, и это включает код в хранимых процедурах и динамично сгенерированных вызовах к хранимым процедурам.
Параметризированные запросы и сохраненный procs, названный с параметрами, оба неуязвимы к инжекции, пока они не используют произвольные исходные данные, чтобы сгенерировать код. Обратите внимание, что существует много динамического кода, который также не уязвим для инжекции (например, целочисленные параметры в динамическом коде).
преимущества в основном (я не уверен, 100% действительно возможны), сохранил находящуюся в procs архитектуру, однако, то, что инжекция может даже быть несколько защищена от (но не отлично) для динамического кода в стороне клиента потому что:
Только ИСПОЛНИТЕЛЬНЫЕ разрешения даны к любому пользовательскому контексту, под которым соединяется приложение, таким образом, любой ВЫБОР, ВСТАВЬТЕ, ОБНОВИТЕ, Запросы на удаление просто перестанут работать. Конечно, ОТБРАСЫВАНИЕ и т.д. не должно быть позволено так или иначе. Таким образом, любая инжекция должна была бы быть в форме ДОЛЖНОСТНОГО ЛИЦА, так в конечном счете только операции, которые Вы определили в своем уровне SP, даже будут доступны (не произвольный SQL) для введения против.
Среди многих других преимуществ определения Ваших сервисов базы данных как ряд хранимых процедур (как любой уровень абстракции в программном обеспечении) способность осуществить рефакторинг Вашу базу данных внизу, не влияя на приложения, способность лучше понять и контролировать шаблоны использования в Вашей базе данных с профилировщиком и способность выборочно оптимизировать в базе данных, не имея необходимость развертывать новые клиенты.
Нет, поскольку Вы могли все еще использовать D-SQL в своих хранимых процедурах... и проверке, и ограничение Вашего входа является хорошей идеей в любом случае.
Кроме того, рассмотрите использование мелкомодульного доступа к базе данных, (также названный обычно основанным на роли Управлением доступом), у основного пользователя Вашей базы данных должны быть точно полномочия, должен был сделать ее задание и ничто иное. Не должны составлять новые таблицы после установки? ОТМЕНИТЕ то разрешение. Разве законная потребность не имеет для выполнения как sysdba? Затем не делайте! Подлая инжекция, сообщающая пользователю к "DROP DATABASE", будет загнана в угол, если пользователь не был ДАН то разрешение. Затем все, о чем необходимо волноваться, является пропускающими данные операторами SELECT.