Сбор информации из сообщений об ошибках
Взлом средств проверки вводимых данных не обязательно введет к взлому приложения. В большинстве случаев он просто вызывает информационную ошибку приложения. Сообщения об информационных ошибках могут содержать пути и имена файлов, названия переменных, описания полей SQL, ошибки сервлетов (включая список используемых и основных сервлетов), сообщения об ошибках баз данных (ADO-ошибки) или любую другую информацию о приложении. Запоминайте все мельчайшие детали в полученной информации, потому что при наличии большого количества мелких частей информации может получиться детальная картина приложения, которая может быть использована при серьезном взломе.
Рекомендации по избеганию большинства взломов
Проверка вводимых данных на стороне сервера
Программное обеспечение клиентской части находится под полным контролем пользователя. Вследствие этого все формы и данные, обрабатывающиеся в Web-браузере, могут быть изменены пользователем. Следовательно, для обеспечения эффективной проверки вводимых данных средства проверки должны располагаться на стороне сервера, вне контроля пользователя.
Кодирование символов
Все символы, передаваемые пользователем приложению, особенно имеющие специальное значение в языках HTML и SQL, должны заменяться соответствующими кодами. Например, угловые скобки должны представляться в виде кодов < и >.
Регулярные выражения
Для проверки вводимых данных необходимо использовать специальные выражения для предотвращения ввода некорректных данных.
Строгое определение типов данных
Для ввода численных значений в приложении должны использоваться только поля для ввода численных значений, а для ввода строковых данных только поля, допускающие ввод лишь строковых значений. Кроме того, везде, где возможно, следует применять ограничение длины вводимых данных.
Продуманная система управления ошибками
Независимо от того, на каком языке написано приложение, обработка ошибок в нем должна соответствовать 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 |
Обход каталогов |
Девочки и мальчики, пацаны и пацанки, дамы и ковалеры, мадамы и
месье, джентельмены и леди,товарищи и братаны-с Наступающим вас Новым
Годом!
Спасибо за ваши труды, всегда вас читаю!
Спасибо за статью, довольно интересно, добавил ваш блог в закладки!