Параметризованные запросы ADO.NET - средство защиты от «SQL Injection» атак 

«SQL Injection» атаки возможны в приложениях, не проверяющих полученные от пользователя данные. Уязвимое приложение использует полученные данные для построения динамического SQL запроса и последующего (его) выполнения. Подобный тип уязвимостей характерен как для веб-приложений (ASP.NET, ASP, PHP и так далее), так и для обычных приложений. Однако, для веб-приложений они наиболее критичны, из-за широкой аудитории пользователей. Возможные последствия атаки:

• Потеря части данных
• Неавторизованный доступ к приложению
• Получение злоумышленником доступа к закрытой информации из БД
• Ошибка выполнения приложения

В этой статье мы рассмотрим борьбу с «SQL Injection» атаками на примере приложения ASP.NET. Приведенный ниже метод, однако, подходит и для приложений Windows Forms.

Примеры «SQL Injection» атак

Рассмотрим, например, форму авторизации на некотором сайте. Фрагмент кода из ASPX файла:

...
<form runat="server">
Name:<br> <asp:TextBox TextMode="SingleLine"
    id="username" runat="server" /><br>
Pass:<br> <asp:TextBox TextMode="Password"
    id="password" runat="server" /><br>
<input type="submit">
</form>
...

Затем в code behind файле:

...
string sqlQuery = "SELECT COUNT(*) FROM Users WHERE UserName='"+username.Text+
                  "' AND Password='" + password.Text + "'"
SqlCommand sqlCmd = new SqlCommand(sqlQuery, sqlConn);
int userCount = (int)sqlCmd.ExecuteScalar();
if (1 == userCount)
{
    // Авторизация пройдена успешно
    ...
}
...

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

admin' --

И тогда наш код сформирует следующий SQL запрос:

SELECT COUNT(*) FROM Users WHERE UserName='admin' --' AND Password='password'

Одинарная кавычка в имени пользователя закрывает ранее открытую одинарную кавычку, а строка «--» превращает в комментарий все, что следует дальше. Соответственно значение пароля не участвует в проверке и если пользователь admin существует, то результатом запроса будет 1 и успешный вход в защищенную часть сайта!

Итак, злоумышленник смог успешно пройти процедуру авторизации на нашем сайте, зная только имя пользователя. Как еще он может использовать найденную уязвимость? Он может ввести в качестве имени пользователя следующую строку:

'; drop table users --

Результатом выполнения такого запроса может стать удаление таблицы Users. Успешность этого шага зависит от привилегий пользователя БД от имени которого выполняется запрос. Следует всегда стараться использовать учетную запись с минимально необходимым набором привилегий и никогда учетную запись администратора БД.

Защита от «SQL Injection» атак

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

...
string sqlQuery = "SELECT COUNT(*) FROM Users WHERE UserName=@username AND Password=@password";
SqlCommand sqlCmd = new SqlCommand(sqlQuery, sqlConn);
sqlCmd.Parameters.Add("@username", SqlDbType.VarChar).Value = username.Text;
sqlCmd.Parameters.Add("@password", SqlDbType.VarChar).Value = password.Text;
int userCount = (int)sqlCmd.ExecuteScalar();
if (1 == userCount)
{
    // Авторизация пройдена успешно
    ...
}
...

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

Еще лучшим методом защиты БД является использование хранимых процедур. Защита базы данных в этом случае обеспечивается за счет того, что пользователю даются только права на выполнение хранимых процедур. Ваш код затем обращается к хранимым процедурам БД от имени подобной непривилегированной учетной записи. Хранимые процедуры в свою очередь выполняют операции INSERT/UPDATE/DELETE. Вызов хранимой процедуры для авторизации пользователя может выглядеть, например, так:

...
SqlCommand sqlCmd = new SqlCommand("CheckLogon", sqlConn);
sqlCmd.CommandType = CommandType.StoredProcedure;
sqlCmd.Parameters.Add ("@username", SqlDbType.VarChar).Value = username.Text;
sqlCmd.Parameters.Add ("@password", SqlDbType.VarChar).Value = password.Text;
int userCount = (int)sqlCmd.ExecuteScalar();
...

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

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

Заключение

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

Автор: Василий Петрухин, статья была взята с сайта relib.com