2016-07-11 4 views
0

Недавно было проверено на хранимой процедуре, закодированной предшественниками для выполнения некоторых CRUD. Это влияет на некритические таблицы в производственной базе данных. Я чувствую, что он уязвим для SQL-инъекций, но кажется, что инъекция действительно безвредна, поскольку она выполняет CRUD на некритических таблицах.Сколько вреда может вызвать SQL-инъекция через эту хранимую процедуру?

Параметр @LocalDatabase передается из файла connectionString="Server=localHost;Database=localDatabase;..." в файле конфигурации.

Мне было интересно, может ли возможная инъекция SQL в этом конкретном SP может катастрофически повредить производственную базу данных? Я взвешиваю экономическую выгоду для перезаписи всего этого модуля.

ALTER PROCEDURE StoredProc_Name 
(
    @LocalDatabase  varchar(50), 
    @Result    int    OUTPUT 
) 

SET @Sql = N'UPDATE <Production Database>.Table1 
SET  ... 
FROM <Production Database>.NewTable INNER JOIN 
     '+ @LocalDatabase +'.dbo.Table1 ON ... INNER JOIN 
     '+ @LocalDatabase +'.dbo.Table2 ON ... 
WHERE NOT EXISTS(SELECT 1 
        FROM <Production Database>.dbo.Table2 
        WHERE .....)' 

EXEC(@Sql) 
SET @Result = @@ROWCOUNT 

Оцените любые рекомендации или помощь в обращении в нужном направлении. Заранее спасибо.

+1

Независимо от угрозы SQL-инъекции ... это действительно плохая практика, я настоятельно рекомендую вам переделать этот код. –

+0

@SufyanJabr почему это так? Могу ли я получить некоторые идеи, чтобы я мог лучше обосновать свое дело, чтобы переписать модуль? Я знаю ... «Он справляется с работой». – f0rfun

+0

Я не знаю конкретного случая, который у вас есть, но с помощью Exec путем объединения SQL является одной из очень плохих практик, и ее следует избегать. Из того, что я вижу, вы пытаетесь переключить базы данных на основе параметра, почему бы вам не сделать это в строке подключения? –

ответ

1

Пока пользователь не влияет на значение, переданное как @LocalDatabase, этот подход будет в порядке. Не использовать динамический SQL было бы лучше, но этот подход может работать ...

+0

спасибо, но могу ли я спросить, является ли дизайн хорошей практикой и почему да или почему нет? – f0rfun

+0

Ну: обычно избегайте динамического SQL рекомендуется по возможности. Я не думаю, что можно динамически изменять базы данных для запроса, поэтому единственной альтернативой является создание копии этого запроса для каждой базы данных в большой инструкции if/else. Это один и тот же запрос много раз, поэтому на самом деле это не помогает поддерживать его в будущем. Поэтому я бы сказал, из-за простоты обслуживания и до тех пор, пока это не приведет к ужасной производительности, я бы позволил этому оставаться только для аспекта обслуживания. –

Смежные вопросы