J3qx

information archive

Аудит Web-приложения – систематизируем тестирование

Posted by j3qx на Апрель 2, 2017

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

Во время тестирования Web-приложения и поиска уязвимостей в нём очень важно придерживаться некоторой методологии, иначе вы можете упустить что-нибудь важное. Чем крупнее приложение, тем важнее для Вас систематизированный подход.

1. Разведка

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

Активная разведка – прямое взаимодействие с сервисом. Изучите исходный код сайта, в нём можно встретить забытые комментарии, обнаружить ссылки и скрипты. Найдите все активные элементы (например, кнопки). Определите все места ввода данных для построения возможных векторов атаки. Соберите почтовые ящики, имена сотрудников. Изучите файл robots.txt, используйте dirbuster для обнаружения доступных папок и файлов. Попробуйте найти режим отладки, параметры разработчика. При сканировании портов nmap’ом не ограничивайтесь стандартными, изучите все 65535 портов. Определите версии включенных сервисов, они могут оказаться уязвимыми.

При тестировании важен как активный, так и пассивный этап разведки. Соберите информацию о сайте с помощью всевозможных сторонних сервисов. Изучите github-аккаунты сотрудников, там можно найти исходные коды внутренних инструментов фирмы. В вакансиях компании можно узнать используемые технологии, версии СУБД и т.д. Используйте дорки для поиска файлов, доменов и прочего. Shodan поможет найти подключенные к интернету устройства. С помощью сервиса Wayback Machine можно найти забытые бекапы и прочее.

2. Тестирование контроля доступа

  • Аутентификация:

Проверьте правила при создании пароля – длину пароля, разрешённые символы. Эти данные помогут нам при подборе паролей.  Протестируйте, есть ли ограничения на количество попыток ввода пароля.
Аналогично протестируйте логин. Проверьте правила для него – возможно, вы сможете обнаружить XSS. В случае реализации правил на стороне клиента – это можно легко обойти, отредактировав код сайта в браузере.
Проверьте форму входа – если при некорректных данных возвращаются разные ответы, то есть возможность подобрать логины. Также протестируйте функцию восстановления аккаунта.
Проверьте функцию “Запомнить меня” – имеет ли она срок действия, уязвим ли соответствующий параметр.
Протестируйте распределение полномочий, проверьте возможность начать какое-либо действие под одним логином, а закончить с его подменой.

  • Управление сессиями:

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

  • Контроль доступа:

Определите разграничения доступа, проверьте контроль доступа для различных пользователей. Протестируйте доступ к методам управления.

3. Проверка входных данных

Проведите фаззинг всех параметров. Попробуйте обнаружить SQL-инъекции, XSS-уязвимости, FPD, LFI и RFI, внедрение шаблона (Server Side и Client Side), прочие инъекции.

4. Тестирование логики приложения

Определите главные цели в логике приложения. Попробуйте обнаружить передачу данных на стороне клиента, их валидацию (тогда вы сможете их корректировать). Изучите многоступенчатые механизмы, попробуйте пропустить один из этапов, например этап оплаты. Проверьте такие компоненты клиента, как Java, ActiveX, Flash. Протестируйте IDOR-уязвимости.

Проверьте наличие мобильного приложения, изучите его на наличие утечек критичной информации.

5. Изучение инфраструктуры приложения

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

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

Изучите все службы на открытых портах. Вы можете обнаружить уязвимый FTP, Proxy или SSH, найти панель управления почтовым клиентом.

Изучите все HTTP-методы. Попробуйте их заменить, так вы сможете обойти фильтрацию.

6. Прочие тесты

Исследуйте DOM-модель на наличие локальных XSS-уязвимостей. Проверьте стойкость SSL. Изучите HTTP-заголовки, параметры cookie.

Протестируйте нашумевшие уязвимости (Heartbleed, ImageTragick и другие).

 

© https://defcon.ru/web-security/4394/

Реклама

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: