1. Что такое атака с помощью SQL-инъекции?
Так называемая атака SQL-инъекцией означает, что злоумышленник вставляет команды SQL в поле ввода веб-формы или строку запроса запроса страницы и обманом заставляет сервер выполнять вредоносные команды SQL. В некоторых формах вводимые пользователем данные используются непосредственно для создания (или воздействия) динамических команд SQL или в качестве входных параметров для хранимых процедур. Такие формы особенно уязвимы для атак с внедрением SQL. Общие процессы атаки с использованием SQL-инъекций включают в себя:
⑴ Веб-приложение ASP.NET имеет страницу входа. Эта страница входа контролирует, имеет ли пользователь право доступа к приложению. От пользователя требуется ввести имя и пароль.
⑵ Содержимое, введенное на странице входа, будет напрямую использоваться для создания динамических команд SQL или непосредственно в качестве параметров хранимых процедур. Вот пример приложения ASP.NET, создающего запрос:
System.Text.StringBuilder query = new System.Text.StringBuilder(
«ВЫБРАТЬ * из пользователей ГДЕ логин = '»)
.Append(txtLogin.Text).Append("' AND пароль='")
.Append(txtPassword.Text).Append("'");
⑶ Злоумышленник вводит что-то вроде «' или '1'='1» в поля ввода имени пользователя и пароля.
⑷ После того, как введенный пользователем контент передается на сервер, сервер запускает приведенный выше код ASP.NET для создания команды SQL для запроса пользователя. Однако, поскольку контент, введенный злоумышленником, очень специфичен, последняя команда SQL. становится: ВЫБРАТЬ * из пользователей ГДЕ логин = '' или '1'='1' И пароль = '' или '1'='1'.
⑸ Сервер выполняет запрос или хранимый процесс для сравнения идентификационной информации, введенной пользователем, с идентификационной информацией, сохраненной на сервере.
⑹ Поскольку команда SQL фактически была изменена в результате атаки путем внедрения и не может по-настоящему аутентифицировать личность пользователя, система неправильно авторизует злоумышленника.
Если злоумышленник знает, что приложение будет использовать содержимое, введенное в форму, непосредственно для запросов проверки личности, он попытается ввести некоторые специальные строки SQL, чтобы подделать запрос, изменить его исходную функциональность и обманом заставить систему предоставить разрешения на доступ.
В зависимости от системного окружения различен и ущерб, который может нанести злоумышленник, который в основном определяется разрешениями безопасности приложения на доступ к базе данных. Если учетная запись пользователя имеет права администратора или другие относительно расширенные права, злоумышленник может выполнять различные операции с таблицами базы данных, которые он хочет выполнить, включая добавление, удаление или обновление данных или даже непосредственное удаление таблицы.
2. Как предотвратить?
К счастью, предотвратить взлом приложений ASP.NET с помощью SQL-инъекций не так уж и сложно. Все, что вам нужно сделать, — это отфильтровать весь входной контент перед использованием входного содержимого формы для создания команды SQL. Фильтрация входных данных может осуществляться различными способами.
⑴ В ситуациях, когда SQL-запросы создаются динамически, можно использовать следующие методы:
Первый: заменить одинарные кавычки, то есть заменить все одинарные кавычки на две одинарные кавычки, чтобы злоумышленники не могли изменить значение команд SQL. Снова взглянув на предыдущий пример: «SELECT * from Users WHERE login = ''' or ''1''=''1' AND pass = ''' or ''1''=''1'», очевидно, получит тот же самый «ВЫБРАТЬ * из пользователей, где логин = '' или '1'='1' И пароль = '' или '1'='1'» разные результаты.
Во-вторых: удалите все дефисы в вводимых пользователем данных, чтобы злоумышленники не могли создавать такие запросы, как «SELECT * from Users WHERE login = 'mas' -- AND pass =''», поскольку суффикс таких запросов Половина из них была прокомментирована. вышел и больше не действителен. Злоумышленнику достаточно знать только законное имя пользователя, и ему не нужно знать пароль пользователя, чтобы успешно получить доступ.
Третье: Ограничьте разрешения учетной записи базы данных, используемой для выполнения запросов. Используйте разные учетные записи пользователей для выполнения операций запроса, вставки, обновления и удаления. Изолируя операции, которые могут выполняться разными учетными записями, он предотвращает использование места, первоначально использовавшегося для выполнения команды SELECT, для выполнения команды INSERT, UPDATE или DELETE.
⑵ Используйте хранимые процедуры для выполнения всех запросов. Способ передачи параметров SQL не позволит злоумышленникам использовать одинарные кавычки и дефисы для проведения атак. Кроме того, он также позволяет ограничить разрешения базы данных, чтобы разрешить выполнение только определенных хранимых процедур. Весь пользовательский ввод должен соответствовать контексту безопасности вызываемой хранимой процедуры, чтобы исключить возможность внедрения атак.
⑶ Ограничьте длину ввода формы или строки запроса. Если имя пользователя содержит не более 10 символов, не допускайте ввода более 10 символов в форму. Это значительно усложнит злоумышленникам вставку вредоносного кода в команды SQL.
⑷ Проверьте законность вводимых пользователем данных и убедитесь, что входной контент содержит только легальные данные. Проверка данных должна выполняться как на стороне клиента, так и на стороне сервера — проверка на стороне сервера выполняется, чтобы компенсировать хрупкую безопасность механизма проверки на стороне клиента.
На стороне клиента злоумышленник вполне может получить исходный код веб-страницы, изменить сценарий, проверяющий легальность (или удалить сценарий напрямую), а затем отправить незаконный контент на сервер через измененную форму. Поэтому единственный способ убедиться в том, что операция проверки действительно была выполнена, — это выполнить проверку также и на стороне сервера. Вы можете использовать множество встроенных объектов проверки, например RegularExpressionValidator, который может автоматически генерировать сценарии на стороне клиента для проверки, и, конечно же, вы также можете вставлять вызовы методов на стороне сервера. Если вы не можете найти готовый объект проверки, вы можете создать его самостоятельно через CustomValidator.
⑸ Зашифруйте и сохраните имя пользователя, пароль и другие данные. Шифрование данных, введенных пользователем, а затем сравнение их с данными, сохраненными в базе данных, эквивалентно «стерилизации» данных, введенных пользователем. Данные, введенные пользователем, больше не имеют особого значения для базы данных, поэтому это предотвращает. злоумышленникам от внедрения команд SQL. Класс System.Web.Security.FormsAuthentication имеет HashPasswordForStoringInConfigFile, который очень подходит для очистки входных данных.
⑹ Проверьте количество записей, возвращенных запросом, извлекшим данные. Если программа требует возврата только одной записи, но фактическая возвращаемая запись состоит из более чем одной строки, это будет рассматриваться как ошибка.