• Категории
  • Подписка
  • Разместить статью
04/12/11 2 7402 Взлом средств проверки вводимы данных
-

Сбор информации из сообщений об ошибках

Взлом средств проверки вводимых данных не обязательно введет к взлому приложения. В большинстве случаев он просто вызывает информационную ошибку приложения. Сообщения об информационных ошибках могут содержать пути и имена файлов, названия переменных, описания полей SQL, ошибки сервлетов (включая список используемых и основных сервлетов), сооб­щения об ошибках баз данных (ADO-ошибки) или любую другую информацию о приложе­нии. Запоминайте все мельчайшие детали в полученной информации, потому что при нали­чии большого количества мелких частей информации может получиться детальная картина приложения, которая может быть использована при серьезном взломе.

Рекомендации по избеганию большинства взломов

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

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

Кодирование символов

Все символы, передаваемые пользователем приложению, осо­бенно имеющие специальное значение в языках HTML и SQL, должны заменяться со­ответствующими кодами. Например, угловые скобки должны представляться в виде кодов &lt и &gt.

Регулярные выражения

Для проверки вводимых данных необходимо использовать специальные выражения для предотвращения ввода некорректных данных.

Строгое определение типов данных

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

Продуманная система управления ошибками

Независимо от того, на каком языке напи­сано приложение, обработка ошибок в нем должна соответствовать Java-концепциям проверки, перехвата исключительной ситуации и выхода из опасного состояния (try, catch и finally). Сначала нужно проверить предпринимаемые действия. Если возникла исключительная ситуация — перехватить ее, а если это не помогло — выйти из опас­ного состояния. Использование этих спецификаций позволяет корректно обрабаты­вать ошибки приложения и предоставлять пользователю информацию, в которой не содержится критических данных системы.

Обязательная аутентификация

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

Использование наименьшего уровня привилегий

Для работы Web-сервера и любых Web-приложений используйте учетную запись, обладающую лишь необходимыми приви­легиями в системе. Это поможет существенно снизить вероятность выполнения про­извольного кода даже в тех случаях, когда злоумышленник взломал приложение. Если он не может получить доступ к каталогу /sbin (в котором хранится большинство ин­струментов для администрирования системы), он практически ничего не сможет сде­лать. Сравните эту ситуацию с той, когда приложение было запущено с привилегиями суперпользователя, вследствие чего хакер, взломав приложение, тут же получил воз­можность выполнять на сервере любые команды.

Итог

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

Поиск возможностей взлома средств проверки вводимых данных следует вести в следующих направлениях:

  • Передача произвольного параметра в GET-запросе.
  • Передача произвольного параметра в POST-запросе.
  • Проверка полей формы (электронные адреса, домашние адреса, имена, комментарии).
  • Проверка полей ввода данных для поиска.
  • Проверка значений, передаваемых в файлах cookie .
  • Проверка задаваемых пользователем переменных среды браузера (User agent, IP address, Operating  System и т.д.).

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

Символ SQL

URL-кодировка

Комментарий

%27

Символ кавычки (апостроф), необходимый для взломав с использованием внедрения SQL

;

%3b

Разделитель команд, завершение строки в сценариях

[null]

%00

Разделитель команд при доступе к файлам, разделитель команд

[return]

%0a

Разделитель команд

+

%2b

Заменяет символ пробела в URL-адресе, часто используется при SQL-внедрении

<

%3c

Открывает HTML-дескриптор

>

%3e

Закрывает HTML-дескриптор

%

%25

Используется для двойного декодирование, поисковых полей, определяет дескрипторы ASP и JSP

?

%3f

Идентификатор РНР-сценария

=

%3d

Достаточно часто используется в URL-параметрах

(

%28

SQL-внедрение

)

%29

SQL-внедрение

[пробел]

%20

Необходим для создания длинных сценариев

.

%2e

Обход каталогов, доступ к файлам

/

%2f

Обход каталогов


2 комментария на «“Сбор информации из сообщений об ошибках”»

  1. Девочки и мальчики, пацаны и пацанки, дамы и ковалеры, мадамы и
    месье, джентельмены и леди,товарищи и братаны-с Наступающим вас Новым
    Годом!

    Спасибо за ваши труды, всегда вас читаю!

  2. Спасибо за статью, довольно интересно, добавил ваш блог в закладки!

Добавить комментарий

Яндекс.Метрика