Что такое Внедрение SQL? [дубликат]

Я нашел, что данная статья была чрезвычайно хорошим чтением о методах Внедрения SQL (ссылка к PDF): Усовершенствованное Внедрение SQL В Приложениях .

Несмотря на "Усовершенствованное" высказывание заголовка, это довольно читаемо, даже если у Вас нет большого знания о Внедрении SQL.

Получить некоторую общую проверку данных статья Wikipedia о Внедрении SQL .

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

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

Точка, где SQL введен, является любой точкой, что Ваше приложение принимает вход от пользователя.

, Становится ли это опасной уязвимостью для Вашего веб-приложения, зависит от того, используется ли этот вход позже в качестве части SQL-запроса, правильно не проверяя его тип и выходя из него при необходимости.

Без надлежащего выхода, некоторый код SQL, 'введенный' пользователем, мог быть выполнен механизмом SQL как код SQL, а не простая строка или значение.

Кто-то может объяснить инжекцию SQL?

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

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

Вредное содержание не должно прибывать от пользователя, это могло быть довольно, что Ваше приложение добирается из любого источника или даже генерирует себя в коде.

Как это вызывает уязвимости?

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

Пример в PHP:

$password = $_POST['password'];
$id = $_POST['id'];
$sql = "UPDATE Accounts SET PASSWORD = '$password' WHERE account_id = $id";

Теперь предположите, что взломщик устанавливает параметры запроса POST на"password=xyzzy"и"id=account_id"приводя к следующему SQL:

UPDATE Accounts SET PASSWORD = 'xyzzy' WHERE account_id = account_id

Хотя я ожидал $id чтобы быть целым числом, взломщик выбрал строку, которая является названием столбца. Конечно, теперь условие верно на каждой строке, таким образом, взломщик только что установил пароль для каждой учетной записи. Теперь взломщик может войти в чей-либо аккаунт - включая привилегированных пользователей.

Где точно точка, где SQL введен?

Это не SQL, это введено, это довольно, что это интерполировало ("введенный") в строку SQL, приводящую к другому виду запроса, чем я предназначил. Я доверял динамическому контенту, не проверяя его и выполнил получающийся SQL-запрос вслепую. Это - то, где проблема запускается.

Внедрение SQL является отказом в коде приложения, не обычно в базе данных или в библиотеке доступа к базе данных или платформе.

Большинства случаев Внедрения SQL можно избежать при помощи параметров запроса. Посмотрите, Как я могу предотвратить Внедрение SQL в PHP? для примеров.

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

$sql = "SELECT  FROM users WHERE username='".$_GET['username']."' AND password='".$_GET['password']."'";

Вред причинен, когда пользователь вводит что-то как

administrator'; --

... для имени пользователя. Без надлежащего кодирования запроса становится:

SELECT * FROM users WHERE username='administrator'; -- AND password=''

Проблема здесь - то, что 'в имени пользователя закрывает поле имени пользователя затем - запускает комментарий SQL, заставляющий сервер базы данных проигнорировать остальную часть строки. Конечным результатом является пользователь, может теперь войти в систему как администратор, не имея необходимость знать пароль. SQL Inection может также использоваться, чтобы выполнить ОБНОВЛЕНИЕ, УДАЛИТЬ или ОТБРОСИТЬ запросы и действительно повредить базу данных.

Внедрение SQL может быть предотвращено при помощи параметризированных запросов или применения Ваших функций выхода языка/инструментария (таких как mysql_real_escape_string () в PHP).

После того как Вы понимаете Внедрение SQL, Вы получите шутку позади этого мультфильма.

SQL-инъекция - это когда вещи, которые должны быть данными, неохотно обрабатываются как SQL-код.

Например, если бы вы сделали

mysql_query("SELECT * FROM posts WHERE postid=$postid");

Обычно вы получали бы сообщение с заданным идентификатором, но предположим, что $ postid установлен в строку 10; DROP TABLE посты - ; внезапно фактический запрос, который вы отправляете, выглядит так:

mysql_query("SELECT * FROM posts WHERE postid=10; DROP TABLE posts --");

Это серьезная проблема, так как вы потеряете всю таблицу сообщений из-за злонамеренного пользователя - о боже.

Самый простой способ предотвратить это - использовать подготовленные операторы, например, через PDO или MySQLi .

Эквивалентным примером в PDO будет

$statement = $db->prepare('SELECT * FROM posts WHERE postid = :postid');
$statement->bindValue(':postid', $postid);
$statement->execute();

. Это гарантирует, что система баз данных знает, что $ postid следует рассматривать как данные, а не код, и, таким образом, будет обрабатываться соответствующим образом.

Вам понравится эта статья из проекта кода; )

Резюме

• Шифрование конфиденциальных данных.
• Доступ к базе данных с использованием учетной записи с минимально необходимыми правами .
• Установите базу данных, используя учетную запись с минимально необходимыми правами .
• Убедитесь, что данные действительны.
• Проведите анализ кода, чтобы проверить возможность атак второго порядка.
• Используйте параметризованные запросы.
• Используйте хранимые процедуры.
• Повторная проверка данных в хранимых процедурах.
• Убедитесь, что сообщения об ошибках ничего не говорят о внутренней архитектуре приложения или базе данных .

На этот вопрос много раз ответили на StackOverflow, но это важная тема, о которой нужно знать всем, поэтому я не собираюсь голосовать за закрытие этого вопроса. вопрос.

Вот ссылки на некоторые из моих прошлых ответов по этой теме:

• Что такое SQL-инъекция?
• Как мне защитить эту функцию от SQL-инъекций?
• Достаточно ли параметров для предотвращения инъекций SQL?
• Является ли SQL-инъекция риском сегодня?

В этом месяце я также выступал с презентацией на конференции MySQL, и мои слайды размещены в Интернете:

• Мифы и заблуждения о SQL-инъекции

SQL-инъекция - это когда злоумышленник вводит SQL в поля ввода, чтобы попытаться запустить SQL на вашем сервере.

Совет №1, которого я придерживаюсь, - использовать параметризованные хранимые процедуры, а не создавать необработанный SQL в коде.

Параметры хранимой процедуры не выполняются, что в большинстве случаев делает их безопасными.