Подтвердить что ты не робот

Что такое SQL-инъекция?

Может кто-нибудь объяснить SQL-инъекцию? Как это вызывает уязвимости? Где именно находится точка, где вводится SQL?

4b9b3361

ОТВЕТЫ

Ответ 1

Может ли кто-нибудь объяснить 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? Например.

Ответ 2

SQL Injection возникает, когда пользователь приложения может влиять на значение запроса к базе данных. Это часто происходит, когда арбинные строки из пользовательского ввода объединяются для создания 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 также может использоваться для выполнения запросов UPDATE, DELETE или DROP и действительно повредить базу данных.

SQL Injection можно предотвратить с помощью параметризованных запросов или применить функции экранирования языка/инструментария (например, mysql_real_escape_string() в PHP).

Как только вы поймете SQL Injection, вы получите анекдот за этот мультфильм.

Ответ 3

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

Например, если вы должны были сделать

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

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

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 следует рассматривать как данные, а не код, и поэтому будет обрабатываться соответствующим образом.

Ответ 5

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

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

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

Ответ 6

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

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

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

Ответ 7

Я нашел эту статью чрезвычайно полезной для чтения о методах SQL-инъекций (ссылка на PDF): Расширенная SQL-инъекция в приложениях SQL Server.

Несмотря на название "Advanced", оно достаточно читаемо, даже если у вас мало знаний о SQL-инъекции.

Ответ 10

CWE

В CWE есть много других эксплойтов, которые нужно изучить.

Ответ 11

Чтобы получить общий фон, просмотрите статью Википедии о SQL Injection.

Короче говоря, атаки SQL-инъекций могут оставить вас уязвимыми для всех утилит кражи данных и их уничтожения. Точные сведения о том, что можно сделать с вашей системой, зависят от деталей самой системы.

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

Ответ 12

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

Резюме

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

Ответ 13

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

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

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