Как защитить ваш сайт от атак SQL-инъекций

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

В более серьезных случаях, когда подключение к серверу базы данных осуществляется через административную учетную запись (например, «root» в MySQL или «sa» в MS SQL Server), злоумышленник может зайти до полной компрометации операционной системы сервера. На серверах Windows это может проявиться в том, что злоумышленник выполняет расширенные хранимые процедуры, такие как xp_cmdshell . В одном случае злоумышленники использовали уязвимость SQL-инъекций для создания учетных записей пользователей на скомпрометированном сервере, включения функции удаленного рабочего стола, настройки общих папок SMB и загрузки вредоносных программ, за исключением того, что они практически испортили все, что хранилось в базе данных.

Как защитить себя от атак SQL-инъекций

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

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

Никогда не доверяйте пользовательскому вводу

Первое правило о пользовательском вводе — « не доверяй и не проверяй », что фактически означает, что все формы пользовательского ввода должны считаться вредоносными, если не доказано иное. Это учитывает не только простые поля ввода, такие как текстовые области и текстовые поля, но и все остальное, например, скрытые входные данные, параметры строки запроса, файлы cookie и загрузки файлов.

Тот факт, что пользовательский интерфейс браузера не позволяет пользователю манипулировать вводом, не означает, что он не может быть подделан. Простые инструменты, такие как Burp Suite, позволяют пользователям захватывать HTTP-запросы и изменять что-либо, в том числе скрытые значения форм, перед отправкой их на сервер. И если вы считаете себя умным с помощью Base64, кодирующей ваши данные, они могут быть легко декодированы, изменены и перекодированы злоумышленниками.

Проверьте входные строки на стороне сервера

Проверка — это процесс проверки того, что пользователи вводят правильный тип ввода, и нейтрализации любых потенциальных вредоносных команд, которые могут быть встроены во входную строку. Например, в PHP вы можете использовать mysql\_real\_escape\_string() для экранирования символов, которые могут изменить характер команды SQL.

Измененная версия ранее упомянутого кода входа будет выглядеть следующим образом:

 $con=mysqli_connect("localhost","user","password","db"); $username = mysqli_real_escape_string($con, $_POST['username']); $password = mysqli_real_escape_string($con, $_POST['password']); $sql_command = "select * from users where username = '" . $username; $sql_command .= "' AND password = '" . $password . "'"; 

Эта простая модификация защитит ваш код от атаки, которая была представлена, путем добавления escape-символа (\) перед одинарными кавычками, которые были намеренно добавлены злонамеренным пользователем.

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

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

Используйте параметры команды

Лучшей альтернативой экранированию было бы использование параметров команды. Параметры команды определяются путем добавления имен заполнителей в команды SQL, которые впоследствии будут заменены пользовательским вводом. ASP.NET имеет очень интуитивно понятный и простой в использовании набор API для этой цели.

Следующий код, написанный на C #, показывает, как вы можете использовать параметры команды для защиты вашего сайта от внедрения SQL:

 SqlCommand cmd = new SqlCommand ("SELECT * FROM users WHERE username=@username AND password=@password",con); SqlParameter username = new SqlParameter(); username.ParameterName = "@username"; username.value = txtUsername.Text; cmd.Parameters.Add(username); SqlParameter password = new SqlParameter(); password.ParameterName = "@password"; password.value = txtPassword.Text; cmd.Parameters.Add(password); 

 $age = (int)$_POST['age']; 

 $sql_command = "select * from users where age = " . $age; 

 $sql_command = "select * from users where age = '" . $age . "'";