Примеры внедрения SQL даже при использовании SQLParameter в .NET?

Question

Я слышал, что SQL-инъекция все еще возможна при использовании ADO.NET SQLParameter (параметризованный запрос) для SQL Server.

Я ищу реальные примеры в коде C # / VB в качестве доказательства.

РЕДАКТИРОВАТЬ: Я ищу конкретные рабочие примеры.Не введение в SQL инъекции или как предотвратить это.

Answer 1

Если вы создаете инструкцию в хранимой процедуре и используете sp_executesql, параметризованный запрос является ложной защитной сеткой.

Answer 2

Здесь есть еще один вопрос о SO с некоторыми отличными ответами на SQL-инъекции ...

Достаточно ли параметров для предотвращения инъекций Sql?

Этот пример взят непосредственно по ссылке выше от Стивена А. Лоу.

Пример, в котором параметр @ p1 должен быть именем таблицы

create procedure dbo.uspBeAfraidBeVeryAfraid ( @p1 varchar(64) ) 
AS
    SET NOCOUNT ON
    declare @sql varchar(512)
    set @sql = 'select * from ' + @p1
    exec(@sql)
GO

Вот дальнейшее чтение ...

• Сетка Майкс Дот
• Форумы ASP.NET
• * MSDN 1026 *

Answer 3

Конкретный пример ...

create procedure dbo.spVulnerable
@firstname varchar(200)
as
exec ('select id from tblPerson where firstname = ''' + @firstname + '''')
go

Возможно, я неправильно понял синтаксис, но как бы вы ни настраивали @firstname, он все равно уязвим к чему-то вроде следующего:

"Joe' or 1=1"

Пока вы используете динамический SQL, вы потенциально уязвимы для внедрения SQL. Кроме использования параметризованного SQL, единственным решением является внесение в белый список вашего ввода (или, если вы чувствуете себя смелым, попробуйте удалить опасные символы).

Answer 4

Скажем, у вас есть каталог товаров для вашего веб-размера, и ваша страница поиска позволяет осуществлять поиск по названию, описанию, цвету и размеру (скажем, вы продаете бюстгальтеры):

create table [products] (
    product_id int identity(1,1) not null primary key
    , name varchar(256)
    , description varchar(max)
    , color varchar(256)
    , size varchar(256));
GO  

create procedure usp_dynamicSearch
    @product varchar(256) = NULL
    , @description varchar(256) = NULL
    , @color varchar(256) = NULL
    , @size varchar(256) = NULL
as
begin
    set nocount on;
    declare @sql nvarchar(max)
        , @and nvarchar(5);
    set @sql = N'SELECT 
        product_id, name, description, color, size 
        FROM products
        WHERE ';
    set @and = N'';
    if (@product is not null) 
    begin
        set @sql = @sql + N'name LIKE ''' + @product + N'''';
        set @and = N' AND ';
    end
    if (@description is not null) 
    begin
        set @sql = @sql + @and + N'description LIKE ''' + @description + N'''';
        set @and = N' AND ';
    end
    if (@color is not null) 
    begin
        set @sql = @sql + @and + N'color = ''' + @color + N'''';
        set @and = N' AND ';
    end
    if (@size is not null) 
    begin
        set @sql = @sql + @and + N'size = ''' + @size + N'''';
    end 
    exec sp_executesql @sql;
end
GO

Вы используете хранимую процедуру, которая динамически создает SQL, подходящий для поиска. Вы вызываете его, передавая параметры:

exec usp_dynamicSearch @color = N'Red', @size = N'58-DD';

Поскольку процедура создает небрежный динамический SQL, она все еще открыта для внедрения SQL:

exec usp_dynamicSearch @color = N'Red', @size = N''';
INSERT INTO products (name, description) 
values (''31337'', ''haxorz!''); 
--';

Нежелательный продукт был помещен в каталог (чтобы сделать это атакующей атакой ...). В этом случае подходящим исправлением является использование параметров и в динамическом SQL, а затем передача параметров в вызов sp_executesql:

alter procedure usp_dynamicSearch
    @product varchar(256) = NULL
    , @description varchar(256) = NULL
    , @color varchar(256) = NULL
    , @size varchar(256) = NULL
as
begin
    set nocount on;
    declare @sql nvarchar(max)
        , @and nvarchar(5);
    set @sql = N'SELECT 
        product_id, name, description, color, size 
        FROM products
        WHERE ';
    set @and = N'';
    if (@product is not null) 
    begin
        set @sql = @sql + N'name LIKE @product';
        set @and = N' AND ';
    end
    if (@description is not null) 
    begin
        set @sql = @sql + @and + N'description LIKE @description';
        set @and = N' AND ';
    end
    if (@color is not null) 
    begin
        set @sql = @sql + @and + N'color = @color';
        set @and = N' AND ';
    end
    if (@size is not null) 
    begin
        set @sql = @sql + @and + N'size = @size';
    end 
    exec sp_executesql @sql , N'@product varchar(256)
        , @description varchar(256)
        , @color varchar(256)
        , @size varchar(256)'
        , @product, @description, @color, @size;
end
GO

Таким образом, sp_executesql и динамический SQL являются главной задачей. Помимо этого, существуют также различные системные процедуры, которые создают динамический SQL под прикрытием, и исторически некоторые из них оказались уязвимыми, особенно в SQL 2000.

Answer 5

Попробуйте поискать уязвимости в ADO.net, может быть уязвимость в безопасности.