Общие проблемы с инъекцией SQL cgi

Я сканировал сайт, когда выскочила следующая уязвимость: CGI Generic SQL Injection.

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

Итак, я продолжил чтение и обнаружил, что уязвимость находится в этом фрагменте кода:

Используя метод POST HTTP, сканер Nessus обнаружил, что:

  • Следующие ресурсы могут быть уязвимы для SQL-инъекций:

  • Параметр _codeTextBox CGI /LoginTeacherForm.aspx:

    /LoginTeacherForm.aspx [loginButton=Login&_VIEWSTATE=dDwtMTU2NDIxMDkwN Ts7Pg%3d%3d&btnChangePassword=Wijzig%20Pincode&_pinCodeTextBox=&_codeTex tBox='+convert(int,convert(varchar,0x7b5d))+']

-------- выход --------

 Exception Details: System.Data.SqlClient.SqlException: String or
binary data would be truncated.
The statement has been terminated. 

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

Итак, мой вопрос заключается в том, как атака сможет фактически взломать сайт и обойти вход в систему и т. Д. (Конечно, только в образовательных целях)


person that guy    schedule 23.08.2013    source источник
comment
это не тот сайт, где можно задавать такие вопросы, он предназначен только для вопросов по программированию: см. здесь security.stackexchange.com   -  person epsilones    schedule 24.08.2013


Ответы (2)


Ошибка System.Data.SqlClient.SqlException указывает на ошибку в операторе SQL-запроса. Это означает, что значение, хранящееся в параметре _codeTextBox, не проверяется или иным образом не очищается перед помещением в запрос.

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

В этом случае похоже, что параметр _codeTextBox передается функции convert. Сомневаюсь, что кто-то мог этим воспользоваться. Но это указывает на небезопасные методы кодирования, которые, вероятно, появляются в других областях, о которых Nessus не знает. Читайте ниже для получения дополнительной информации.

Чаще всего я вижу это, когда программист просто объединяет значения со строкой SQL-запроса:

Небезопасный пример (java) (Источник OWASP)

String query = "SELECT account_balance FROM user_data WHERE user_name = "
  + request.getParameter("customerName");

try {
    Statement statement = connection.createStatement( … );
    ResultSet results = statement.executeQuery( query );
}

Поскольку значение просто добавляется в конец запроса, пользователь может изменить запрос, чтобы сделать что-то гнусное, например, войти в систему как любой пользователь или просмотреть все транзакции. В приведенном выше примере пользователь может изменить параметр customer name на что-то вроде '' or 1=1 или хуже.

Ожидаемый запрос:

 SELECT account_balance FROM user_data WHERE user_name = someuser

Неверный запрос:

 SELECT account_balance FROM user_data WHERE user_name = '' OR 1=1

OWASP рекомендует следующие защитные меры. Ваша ситуация будет диктовать, что уместно:

Основные средства защиты:

  1. Использование подготовленных операторов (параметризованных запросов)
  2. Использование хранимых процедур
  3. Экранирование всех введенных пользователем данных

Дополнительные средства защиты:

  • Также принудительно: наименьшие привилегии
  • Также выполните: Проверка ввода белого списка

Вам действительно нужно посетить сайт OWASP и узнать больше о SQL-инъекция.

person ZnArK    schedule 09.09.2013

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

Чтобы проверить себя, попробуйте запрос с _codeTextBox=, установленным в одинарную кавычку, чтобы увидеть, получаете ли вы все еще SqlException. Если это так, измените это на две одинарные кавычки, и если ошибка исчезнет, ​​вы, вероятно, уязвимы.

person SilverlightFox    schedule 27.08.2013