Предотвращают ли хранимые процедуры SQL-инъекцию?

Правда ли, что хранимые процедуры предотвращают атаки SQL-инъекций на базы данных PostgreSQL? Я провел небольшое исследование и выяснил, что SQL Server, Oracle и MySQL не защищены от внедрения SQL, даже если мы используем только хранимые процедуры. Однако эта проблема не существует в PostgreSQL.

Предотвращает ли реализация хранимых процедур в ядре PostgreSQL атаки SQL-инъекций или это что-то еще? Или PostgreSQL также подвержен внедрению SQL, даже если мы используем только хранимые процедуры? Если да, пожалуйста, покажите мне пример (например, книга, сайт, бумага и т. Д.).

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

Этот код сервера SQL:

CREATE PROCEDURE [dbo].[sp_colunmName2]   
    @columnName as nvarchar(30),
    @type as nvarchar(30), 
    @searchText as nvarchar(30)           
AS
BEGIN
    DECLARE @SQLStatement NVARCHAR(4000)
    BEGIN
        SELECT @SQLStatement = 'select * from Stations where ' 
            + @columnName + ' ' + @type + ' ' + '''' + @searchText + '''' 
        EXEC(@SQLStatement)
    END      
END
GO

примерно эквивалентно postgres:

CREATE or replace FUNCTION public.sp_colunmName2 (
    columnName  varchar(30),
    type varchar(30), 
    searchText  varchar(30) ) RETURNS SETOF stations LANGUAGE plpgsql            
AS
$$
DECLARE SQLStatement VARCHAR(4000);
BEGIN
    SQLStatement = 'select * from Stations where ' 
            || columnName || ' ' || type || ' ' || ''''|| searchText || '''';
    RETURN QUERY EXECUTE  SQLStatement;
END
$$;

Идея разработчика состояла в том, чтобы создать универсальную процедуру поиска, но в результате предложение WHERE может содержать все, что хочет пользователь, что позволяет посещать маленькие таблицы Бобби .

Используете ли вы операторы SQL или хранимую процедуру, не имеет значения. Важно то, использует ли ваш SQL параметры или конкатенированные строки. Параметры предотвращают внедрение SQL; объединенные строки позволяют SQL-инъекцию.

Атаки SQL-инъекцией - это атаки, в которых ненадежный ввод представляет собой непосредственно добавленные запросы, что позволяет пользователю эффективно выполнять произвольный код, как показано в этом каноническом комиксе XKCD.

Таким образом, мы получаем ситуацию:

userInput = getFromHTML # "Robert ') Удалить таблицу студентов; -"

Query = "Выбрать * из студентов, где studentName =" + userInput

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

В хранимой процедуре, в большинстве БД (и программ, не забывайте, что предварительно скомпилированные запросы считаются хранимыми процедурами) выглядят следующим образом:

 

создать сохраненную процедуру foo (
выберите * из студентов, где studentName =: 1
);

Затем, когда программа желает получить доступ, она вызывает foo(userInput)и счастливо получает результат.

Хранимая процедура не является волшебной защитой от SQL-инъекций, поскольку люди вполне могут писать плохие хранимые процедуры. Тем не менее, предварительно скомпилированные запросы, хранящиеся ли они в базе данных или в программе, намного труднее открыть дыры в безопасности, если вы понимаете, как работает SQL-инъекция.

Вы можете прочитать больше о SQL-инъекции:

• В этой дискуссии Джефф Этвуд
• Профилактическая шпаргалка
• Как атаковать ваш собственный код (Убедитесь, что ваш QA включает тестирование безопасности. Если этого не произойдет, ваш сайт будет проверен на безопасность извне. Это плохо.)

Да, в некоторой степени.
Хранимые процедуры сами по себе не помешают внедрению SQL.

Позвольте мне сначала процитировать SQL-инъекцию из OWASP

Атака SQL-инъекции состоит из вставки или «внедрения» SQL-запроса через входные данные от клиента к приложению. Успешный SQL-инъекционный эксплойт может считывать конфиденциальные данные из базы данных, изменять данные базы данных (вставлять / обновлять / удалять), выполнять операции администрирования базы данных (например, выключать СУБД), восстанавливать содержимое данного файла, присутствующего в файле СУБД система и в некоторых случаях выдает команды операционной системе. Атаки с использованием SQL-инъекций представляют собой тип атаки с использованием инъекций, в которой команды SQL вводятся во входные данные плоскости данных для выполнения предопределенных команд SQL.

Вы должны санировать вводимые пользователем данные и не объединять операторы SQL, даже если вы используете хранимую процедуру.

Джефф Эттвуд объяснил последствия объединения SQL в « Дайте мне параметризованный SQL, или дайте мне смерть »

Ниже приводится интересный мультфильм, который мне приходит в голову всякий раз, когда я слышу SQL-инъекцию. Думаю, вы поняли :-)

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

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

Хранимые процедуры добавляют дополнительный уровень безопасности, применяя неверный синтаксис при объединении, но не являются «более безопасными», если в них используется, скажем, динамический SQL.

Итак, ваш код выше вызван объединением этих строк

• exec sp_GetUser '
• x' AND 1=(SELECT COUNT(*) FROM Client); --
• ' , '
• monkey
• '

Это дает неверный синтаксис, к счастью

Параметризация это дало бы

exec sp_GetUser 'x'' AND 1=(SELECT COUNT(*) FROM Client); --' , 'monkey'

Это означает

• @UserName знак равно x' AND 1=(SELECT COUNT(*) FROM Client); --
• @Password знак равно monkey

Теперь в приведенном выше коде вы не получите строк, потому что я предполагаю, что у вас нет пользователя x' AND 1=(SELECT COUNT(*) FROM Client); --

Если хранимый процесс выглядел следующим образом (с использованием сцепленного динамического SQL ), то ваш параметризованный хранимый вызов proc все еще разрешит SQL-инъекцию

...
SET @sql = 'SELECT userName from users where userName = ''' + 
               @UserName + 
               ''' and userPass = ''' +
               @Password +
               ''''
EXEC (@sql)
....

Итак, как показано, конкатенация строк является главным врагом для внедрения SQL

Хранимые процедуры добавляют инкапсуляцию, обработку транзакций, ограниченные разрешения и т. Д., Но их все еще можно использовать для внедрения SQL.

Вы можете посмотреть на переполнение стека для получения дополнительной информации о параметризации

«Атака инъекции SQL происходит , когда пользовательский ввод неправильно закодирован. Как правило, ввод данных пользователя некоторые данные пользователя отправляемые с ее запросом, то есть значения в $_GET, $_POST, $_COOKIE, $_REQUESTили $_SERVERмассивы. Однако, пользовательский ввод могут также поступать из множества других источники, такие как сокеты, удаленные веб-сайты, файлы и т. д. Поэтому вы должны действительно рассматривать все, кроме констант (например 'foobar'), как ввод данных пользователем ".

Недавно я тщательно изучал эту тему и хотел бы поделиться с другими довольно интересным материалом, чтобы сделать этот пост более полным и поучительным для всех.

• Предотвращение SQL-инъекций с помощью PHP Джон Небель
• Уголок безопасности - SQL-инъекция Криса Шифлетта
• Неожиданная SQL-инъекция Александра Андонова
• Mysql_real_escape_string () против подготовленных заявлений Ильи Альшанецкого
• Атака SQL-защиты и защита Сагар Джоши
• Атаки SQL-инъекции профессором Джимом Уайтхедом
• addlashes () против mysql_real_escape_string () Крис Шифлетт
• Что такое ошибка SQL-инъекции? Джоэл Спольски
  
  
• MySQL - предотвращение внедрения SQL
• Пошаговое руководство по SQL-инъекциям
• Шпаргалка по SQL-инъекциям
• Подготовленные заявления в PHP и MySQLi

С YouTube

• Мифы и ошибки SQL-инъекций: лучшие практики защиты от Билла Карвина
• Учебники по PHP: безопасность - SQL-инъекция
• Как вводить SQL с SQLMAP на Backtrack5 RC1

Из Википедии

• Википедия - SQL-инъекция
• Википедия - SQL

От OWASP

• SQL-инъекция
• Руководство по внедрению SQL
• OWASP - как избежать SQL-инъекций
• Шпаргалка по предотвращению инъекций SQL
• Тестирование на SQL-инъекцию

Из руководства по PHP

• SQL-инъекция
• Класс PDO - подготовленные операторы и хранимые процедуры
• MySQL Улучшенное расширение
• mysql_real_escape_string ()

От Microsoft и Oracle

• Как правильно предотвратить внедрение SQL-кода в PHP-скриптах от Microsoft
• Прекратить атаки SQL-инъекций, прежде чем они остановят вас Microsoft
• Защита от атак SQL-инъекций Oracle

Переполнение стека

• SQL-инъекции и библиотека ADOdb! Общая безопасность сайта PHP с примерами
• Лучший способ предотвратить SQL-инъекцию в PHP
• XKCD SQL инъекция - пожалуйста, объясните
• Каков наилучший способ избежать атак с использованием SQL-инъекций?
• Что такое SQL-инъекция?
• SQL-инъекция на INSERT
• Как защитить эту функцию от SQL-инъекций?
• Достаточно ли параметров для предотвращения инъекций Sql?
• Является ли инъекция SQL риском сегодня?
• SQL-инъекция
• SQL-инъекция этического взлома
• Этот код предотвращает внедрение SQL?

Сканер SQL-инъекций

• 15 лучших сканеров SQL-инъекций
• Netsparker Community Edition, бесплатный SQL-инъекционный сканер и XSS-сканер

Хранимые процедуры магическим образом не предотвращают внедрение SQL, но они значительно упрощают его предотвращение. Все, что вам нужно сделать, это что-то вроде следующего (пример Postgres):

CREATE OR REPLACE FUNCTION my_func (
  IN in_user_id INT 
)
[snip]
  SELECT user_id, name, address FROM my_table WHERE user_id = in_user_id; --BAM! SQL INJECTION IMMUNE!!
[snip]

Это оно! Проблема возникает только при формировании запроса с помощью конкатенации строк (например, динамический SQL), и даже в этих случаях вы можете связать! (Зависит от базы данных.)

Как избежать внедрения SQL в ваш динамический запрос:

Шаг 1) Спросите себя, действительно ли вам нужен динамический запрос. Если вы соединяете строки только для того, чтобы установить ввод, то вы, вероятно, делаете это неправильно. (Из этого правила есть исключения - одно исключение относится к отчетам о запросах в некоторых базах данных. У вас могут быть проблемы с производительностью, если вы не заставляете его скомпилировать новый запрос при каждом выполнении. Но изучите эту проблему, прежде чем переходить к этому. )

Шаг 2) Изучите правильный способ установки переменной для вашей конкретной СУБД. Например, Oracle позволяет вам делать следующее (цитируя их документы):

sql_stmt := 'UPDATE employees SET salary = salary + :1 WHERE ' 
           || v_column || ' = :2';
EXECUTE IMMEDIATE sql_stmt USING amount, column_value; --INJECTION IMMUNE!!

Здесь вы все еще не объединяете входные данные. Вы в безопасности! Ура!

Если ваша база данных не поддерживает что-то подобное выше (надеюсь, что ни один из них все еще не настолько плох, но я не удивлюсь) - или если вам все еще действительно нужно объединить свои данные (как в «иногда» случае представления запросов как Я намекал выше), тогда вы должны использовать правильную функцию выхода. Не пиши это сам. Например, postgres предоставляет функцию quote_literal (). Таким образом, вы бы запустить:

sql_stmt := 'SELECT salary FROM employees WHERE name = ' || quote_literal(in_name);

Таким образом, если in_name является чем-то коварным, как '[snip] или 1 = 1' (часть "или 1 = 1" означает выбрать все строки, позволяя пользователю видеть зарплаты, которые он не должен!), То quote_literal сохраняет ваш зад сделать результирующую строку:

SELECT salary FROM employees WHERE name = '[snip] or 1=1'

Результаты не будут найдены (если у вас нет сотрудников с действительно странными именами.)

В этом суть! Теперь позвольте мне оставить вам ссылку на классическую статью гуру Oracle Тома Кайта на тему SQL-инъекций, чтобы понять суть : Linky