Привет, Codeby!
В прошлой статье я рассмотрел общий подход к тестированию веб-приложений, основаный на OWASP Testing Guide.
Сегодня получим еще небольшую дозу теории и уже приступим к практической части.
Считайте этот текст вольным и адаптированным (под меня)) переводом данного руководства.
Угроза — это все, что может нанести ущерб активам системы, используя уязвимость. Угрозой может быть внешний атакующий, внутренний пользователь системы, нестабильность системы и т.д.
Активы системы — данные в БД или файловой системы, функции системы, даже мощности оборудования, на котором работает система.
Тест - это действие, демонстрирующее, что приложение соответствует требованиям безопасности заинтересованных сторон.
В ходе тестирования важно документировать все действия и результаты этих действий. Вы можете создать таблицу в exel, или использовать записную книжку. Мне нравится приложение CherryTree - записная книжка с иерархической структурой.
Тестирование безопасности веб-приложений не является и никогда не будет являться точной наукой, так как каждое веб-приложение по-своему уникально. При проектировании приложений могут использоваться разные технологии, разные комбинации этих технологий, версии одного и того же ПО могут отличаться, и даже если не отличаются версии, то может отличаться их конфигурация. Поэтому тестирование конкретного веб-приложения — это лишь метод тестирования безопасности, подходящий при конкретных обстоятельствах.
Иными словами, если перед нами на первый взгляд три абсолютно одинаковых интернет-магазина на OpenCart, это не значит, что они одинаковы на самом деле. Может быть один из них крутится на веб-сервере apache, второй на nginx, а третий тоже на nginx, но использует не MySQL, как первые два, а PostgreSQL. Суть, думаю, ясна.
Цель проекта OWASP Testing Guide — собрать все возможные методы тестирования, объяснить их и постоянно обновлять руководство. Метод тестирования основан на подходе
Тестирование делится на два этапа:
Пассивный режим — когда тестер пытается понять логику приложения и играет с ним. Могут быть использованы инструменты для сбора информации, например http-прокси для мониторинга всех http-запросов и ответов. В конце этого этапа тестер должен выявить все точки входа приложения (http-заголовки, параметры, cookie).
Например, пентестер может обнаружить такой URL:
Он может указывать на форму аутентификации, где пользователь должен ввести логин и пароль.
Следующий URL представляет две точки входа приложения:
Тут мы имеем два параметра, параметр a и параметр b, посредством которых передаются пользовательские данные.
Обнаружив все точки входа, запишите их в таблицу. Они будут нужны на втором, активном этапе тестирования.
Активный режим — в ходе которого тестер должен собрать информацию о приложении, протестировать конфигурацию, управление идентификацией, аутентификацию, авторизацию, входные данные, бизнес-логику и так далее.
Используйте
Первым по списку в чек-листе идет сбор информации с помощью поисковых систем.
Существуют прямые и косвенные методы сбора информации и разведки о целевом веб-приложении в поисковых системах. К прямым методам относится поиск индексов и связанного с ним содержимого в кэше поисковых систем. К косвенным методам относится получение информации о структуре приложения и другой чувствительной информации на форумах, новостных ресурсах и других сайтах.
Как только робот поисковой системы завершил сканирование страниц веб-приложения, он индексирует содержимое его страниц, основываясь на тегах и их атрибутах, для предоставления релевантных результатов поиска. При индексации страниц поисковые системы опираются на метафайлы вебсервера и метатеги, встроенные в html-страницы, которые укзывают роботу, можно или нельзя индексировать данную страницу. Если файл robots.txt не обновляется на протяжении существования веб-приложения, а встроенные метатеги, которые инструктируют роботов не индексировать контент, не используются, то в индексе могут оказаться такие веб-страницы, которые не должны были там оказаться.
Допустим, вы владелец интернет-магазина. Изначально мета-теги и robots.txt были настроены правильно и ничего лишнего в выдачу поисковиков не попало. Потом вы решили изменить или добавить новый функционал к магазину. Суть его в том, что зарегистрированный покупатель из своего личного кабинета может просмотреть информацию о своих прошлых покупках, такую как дата заказа, наименование товара, адрес доставки, номер телефона покупателя, способ платежа и так далее, то есть то, что не должны видеть посторонние люди и тем более это не должно попасть в выдачу поисковиков. Но вот правильно настроить магазин после этого забыли. Результат может быть таким, как на скриншотах ниже:
Пример 1.
Пример 2.
Тот факт, что такие веб-страницы в принципе доступны для просмотра неаутентифицированным юзерам — тема другого раздела, до которого нам еще далеко. Но то, что они оказались в выдаче гугла — это результат неправильной настройки robots.txt и тегов meta в html-страницах.
Вообразим другую ситуацию. Вы решили обновить свой сайт, а старую версию сайта временно разместили по адресу old.mysite.ru. Через какое-то время старую версию вы удалили окончательно, и больше не переживаете за нее, а зря и вот почему:
Пример 3.
В кэше поисковых систем может быть сохраненная копия некоторых страниц. Злоумышленник, вероятно, изучит их и найдет там старые сообщения админов, емайлы, которые вы хотели бы скрыть, или еще что-нибудь интересное.
В данном случае ничего опасного нет, не переживайте
но для примера сойдет.
Мы использовали прямой метод получения информации о цели. А что же с косвенным?
Представьте, что разработчики вашего интернет-магазина для удобства использовали какой-нибудь git-репозиторий, на который они выложили весь исходный код магазина и по какой-то причине, уже не зависящей от вас, репозиторий был проиндексирован поисковиком. Таким образом в руках злоумышленника может оказать информация о структуре вашего сайта, что сильно поможет ему при дальнейшем поиске уязвимостей.
Так же в поиске нужной информации вам могут помочь приожения, которые делают архивные копии сайтов со всего интернета, к примеру
Рассмотрим еще один кейс с примером. Мы тестируем сайт, о владельцах которого нам известно мало или неизвестно ничего. На сайте находим такую информацию:
Пример 4.
UK Registered Company Number — меня заинтересовал этот идентификатор. Не знаю, что это, наверное что-то типа нашего ИНН. После быстрого гугления находим сайт, на котором по данному номеру можно получить некоторые данные о компании и владельцах:
Пример 5.
В результате имеем два имени, даты их рождения и адреса. Такая информация может пригодиться при подборе паролей к административным интерфейсам. Кроме того, имея эти данные мы можем поискать другие веб-приложения, принадлежащие тем же людям.
Ищите и обрящете. Мало ли, что попадет в гугл и как это "что" вам поможет далее.
Подведение итогов. Как тестировать:
С помощью поисковых систем попытайтесь найти:
- файлы конфигурации, логи и информацию о структуре целевого приложения
- сообщения админов сайта и других ключевых лиц
- логины и пароли пользователей
- тексты сообщений об ошибках
- тестовые, промежуточные, старые версии сайта
Изучите и используйте специальные операторы поисковых систем, которые будете использовать при тестировании. Вот, например, хорошая статья на Хабре про поисковые операторы Гугла. Не ограничивайтесь Гуглом, поскольку другие поисковые системы могут выдавать другие результаты поиска. Рассмотрите возможность использования следующих поисковых систем:
Baidu
binsearch.info
Bing
Duck Duck Go
ixquick/Startpage
Google
Yandex
Shodan
DuckDuckGo и ixquick/Startpage обеспечивают некоторую анонимность для пентестера. Shodan выполняет поиск по устройствам или как говорят сегодня, поисковик по интернету вещей. Google имеет полезный оператор «cashe:».
В этом списке должен еще быть поисковик PunkSpider, но у меня он почему-то ни разу не открылся.
В ходе поиска задействуйте свою фантазию и терпение и тогда вам обязательно повезет
В прошлой статье я рассмотрел общий подход к тестированию веб-приложений, основаный на OWASP Testing Guide.
Сегодня получим еще небольшую дозу теории и уже приступим к практической части.
Считайте этот текст вольным и адаптированным (под меня)) переводом данного руководства.
Ссылка скрыта от гостей
— оценка уязвимости программного обеспечения к различным атакам.
Ссылка скрыта от гостей
— это такой недостаток в системе, используя который, можно нарушить целостность системы или вызвать ее неправильную работу.Угроза — это все, что может нанести ущерб активам системы, используя уязвимость. Угрозой может быть внешний атакующий, внутренний пользователь системы, нестабильность системы и т.д.
Активы системы — данные в БД или файловой системы, функции системы, даже мощности оборудования, на котором работает система.
Тест - это действие, демонстрирующее, что приложение соответствует требованиям безопасности заинтересованных сторон.
В ходе тестирования важно документировать все действия и результаты этих действий. Вы можете создать таблицу в exel, или использовать записную книжку. Мне нравится приложение CherryTree - записная книжка с иерархической структурой.
Тестирование безопасности веб-приложений не является и никогда не будет являться точной наукой, так как каждое веб-приложение по-своему уникально. При проектировании приложений могут использоваться разные технологии, разные комбинации этих технологий, версии одного и того же ПО могут отличаться, и даже если не отличаются версии, то может отличаться их конфигурация. Поэтому тестирование конкретного веб-приложения — это лишь метод тестирования безопасности, подходящий при конкретных обстоятельствах.
Иными словами, если перед нами на первый взгляд три абсолютно одинаковых интернет-магазина на OpenCart, это не значит, что они одинаковы на самом деле. Может быть один из них крутится на веб-сервере apache, второй на nginx, а третий тоже на nginx, но использует не MySQL, как первые два, а PostgreSQL. Суть, думаю, ясна.
Цель проекта OWASP Testing Guide — собрать все возможные методы тестирования, объяснить их и постоянно обновлять руководство. Метод тестирования основан на подходе
Ссылка скрыта от гостей
или Черный Ящик, когда тестеру ничего заранее неизвестно о тестируемом приложении или известно очень мало.Тестирование делится на два этапа:
Пассивный режим — когда тестер пытается понять логику приложения и играет с ним. Могут быть использованы инструменты для сбора информации, например http-прокси для мониторинга всех http-запросов и ответов. В конце этого этапа тестер должен выявить все точки входа приложения (http-заголовки, параметры, cookie).
Например, пентестер может обнаружить такой URL:
https://www.example.com/login/Authentic_Form.htmlОн может указывать на форму аутентификации, где пользователь должен ввести логин и пароль.
Следующий URL представляет две точки входа приложения:
http://www.example.com/Appx.jsp?a=1&b=1Тут мы имеем два параметра, параметр a и параметр b, посредством которых передаются пользовательские данные.
Обнаружив все точки входа, запишите их в таблицу. Они будут нужны на втором, активном этапе тестирования.
Активный режим — в ходе которого тестер должен собрать информацию о приложении, протестировать конфигурацию, управление идентификацией, аутентификацию, авторизацию, входные данные, бизнес-логику и так далее.
Используйте
Ссылка скрыта от гостей
в ходе тестирования, что бы ничего не забыть и не пропустить.Сбор информации
Сбор информации с помощью поисковых систем.
Определение веб-сервера.
Обнаружение утечек информации в метефайлах веб-сервера.
Определение всех приложений на веб-сервере.
Обнаружение утечек информации в комментариях исходного кода и метаданных веб-страниц.
Определение точек входа.
Составление карты приложения.
Определение фреймворка приложения.
Определение веб-приложения.
Составление карты архитектуры приложения.
Тестирование управления конфигурацией
Тестирование конфигурации инфраструктуры/сети.
Тестирование конфигурации платформы приложения.
Исследование расширений файлов.
Обнаружение старых версий, резервных копий, незарегистрованных файлов.
Обнаружение административных интерфейсов.
Тестирование HTTP-методов.
Тестирование HTTP Strict Transport Security.
Тестирование кроссдоменных политик.
Тестирование прав доступа к файлам.
Тестирование управления идентификацией
Определение ролей пользователей.
Тестирование процесса регистрации.
Тестирование процесса предоставления аккаунта.
Перечисление аккаунтов, имен пользователей.
Определение политики образования имен пользователей.
Тестирование аутентификации
Передача учетных данных по зашифрованным каналам.
Учетные данные по умолчанию.
Тестирование механизма блокировки аккаунтов.
Обход схемы аутентификации.
Тестирование функции "Запомнить пароль".
Выявление слабых мест в кеше браузера.
Тестирование надежности политики паролей.
Тестирование политики секретных вопросов/ответов.
Тестирование функциональности иземенения и сброса пароля.
Тестирование аутентификации через альтернативные каналы.
Тестирование авторизации
Тестирование Directory traversal/file include.
Обход схемы авторизации.
Повышение привелегий.
Небезопасные ссылки на объекты.
Управление сессиями
Обход схемы управления сессиями.
Атрибуты файлов cookie.
Захват сессии.
Раскрытие переменных сессии.
Тестирование CSRF.
Завершение сессии.
Таймаут сессии.
Session Puzzling.
Тестирование входных данных
Отраженные XSS.
Хранимые XSS.
Подделка HTTP-заголовков.
Загрязнение HTTP-параметров.
SQL Injection.
- Oracle
- MySQL
- SQL Server
- PostgreSQL
- MS Access Testing
- Тестирование NoSQL
LDAP Injection.
ORM Injection.
XML Injection.
SSI Injection.
XPath Injection.
IMAP/SMTP Injection.
Инъекции кода.
- Local File Inclusion
- Remote File Inclusion
Инъекции команд ОС.
Переполнение буфера.
- Heap Overflow
- Stack Overflow
- Format String
Incubated Vulnerability.
HTTP Splitting/Smuggling.
Мониторинг HTTP-запросов.
Обработка ошибок
Коды ошибок.
Трассировка стека.
Недостатки криптографии
Слабые шифры SSL/TLS, недостаточная защита транспортного уровня.
Padding Oracle.
Чувствительная информация, отправляемая через незашифрованные каналы.
Слабое шифрование.
Тестирование бизнес-логики
Проверка валидности данных.
Тест на подделку запросов.
Проверка целостности.
Тестирование таймингов.
Предельное количество выполнений одной функции.
Тестирование обхода рабочих процессов.
Защита от неправильного использования приложения.
Загрузка непредвиденных типов файлов.
Загрузка вредоносных файлов.
Тестирование клиентской части
DOM-based XSS.
Исполнение JavaScript.
HTML Injection.
Client Side URL Redirect.
CSS Injection.
Манипуляция ресурсами на стороне клиента.
Cross Origin Resource Sharing.
Cross site flashing (XSF).
Кликджекинг.
WebSockets.
Web Messaging.
Локальное хранилище.
Сбор информации с помощью поисковых систем.
Определение веб-сервера.
Обнаружение утечек информации в метефайлах веб-сервера.
Определение всех приложений на веб-сервере.
Обнаружение утечек информации в комментариях исходного кода и метаданных веб-страниц.
Определение точек входа.
Составление карты приложения.
Определение фреймворка приложения.
Определение веб-приложения.
Составление карты архитектуры приложения.
Тестирование управления конфигурацией
Тестирование конфигурации инфраструктуры/сети.
Тестирование конфигурации платформы приложения.
Исследование расширений файлов.
Обнаружение старых версий, резервных копий, незарегистрованных файлов.
Обнаружение административных интерфейсов.
Тестирование HTTP-методов.
Тестирование HTTP Strict Transport Security.
Тестирование кроссдоменных политик.
Тестирование прав доступа к файлам.
Тестирование управления идентификацией
Определение ролей пользователей.
Тестирование процесса регистрации.
Тестирование процесса предоставления аккаунта.
Перечисление аккаунтов, имен пользователей.
Определение политики образования имен пользователей.
Тестирование аутентификации
Передача учетных данных по зашифрованным каналам.
Учетные данные по умолчанию.
Тестирование механизма блокировки аккаунтов.
Обход схемы аутентификации.
Тестирование функции "Запомнить пароль".
Выявление слабых мест в кеше браузера.
Тестирование надежности политики паролей.
Тестирование политики секретных вопросов/ответов.
Тестирование функциональности иземенения и сброса пароля.
Тестирование аутентификации через альтернативные каналы.
Тестирование авторизации
Тестирование Directory traversal/file include.
Обход схемы авторизации.
Повышение привелегий.
Небезопасные ссылки на объекты.
Управление сессиями
Обход схемы управления сессиями.
Атрибуты файлов cookie.
Захват сессии.
Раскрытие переменных сессии.
Тестирование CSRF.
Завершение сессии.
Таймаут сессии.
Session Puzzling.
Тестирование входных данных
Отраженные XSS.
Хранимые XSS.
Подделка HTTP-заголовков.
Загрязнение HTTP-параметров.
SQL Injection.
- Oracle
- MySQL
- SQL Server
- PostgreSQL
- MS Access Testing
- Тестирование NoSQL
LDAP Injection.
ORM Injection.
XML Injection.
SSI Injection.
XPath Injection.
IMAP/SMTP Injection.
Инъекции кода.
- Local File Inclusion
- Remote File Inclusion
Инъекции команд ОС.
Переполнение буфера.
- Heap Overflow
- Stack Overflow
- Format String
Incubated Vulnerability.
HTTP Splitting/Smuggling.
Мониторинг HTTP-запросов.
Обработка ошибок
Коды ошибок.
Трассировка стека.
Недостатки криптографии
Слабые шифры SSL/TLS, недостаточная защита транспортного уровня.
Padding Oracle.
Чувствительная информация, отправляемая через незашифрованные каналы.
Слабое шифрование.
Тестирование бизнес-логики
Проверка валидности данных.
Тест на подделку запросов.
Проверка целостности.
Тестирование таймингов.
Предельное количество выполнений одной функции.
Тестирование обхода рабочих процессов.
Защита от неправильного использования приложения.
Загрузка непредвиденных типов файлов.
Загрузка вредоносных файлов.
Тестирование клиентской части
DOM-based XSS.
Исполнение JavaScript.
HTML Injection.
Client Side URL Redirect.
CSS Injection.
Манипуляция ресурсами на стороне клиента.
Cross Origin Resource Sharing.
Cross site flashing (XSF).
Кликджекинг.
WebSockets.
Web Messaging.
Локальное хранилище.
Первым по списку в чек-листе идет сбор информации с помощью поисковых систем.
Существуют прямые и косвенные методы сбора информации и разведки о целевом веб-приложении в поисковых системах. К прямым методам относится поиск индексов и связанного с ним содержимого в кэше поисковых систем. К косвенным методам относится получение информации о структуре приложения и другой чувствительной информации на форумах, новостных ресурсах и других сайтах.
Как только робот поисковой системы завершил сканирование страниц веб-приложения, он индексирует содержимое его страниц, основываясь на тегах и их атрибутах, для предоставления релевантных результатов поиска. При индексации страниц поисковые системы опираются на метафайлы вебсервера и метатеги, встроенные в html-страницы, которые укзывают роботу, можно или нельзя индексировать данную страницу. Если файл robots.txt не обновляется на протяжении существования веб-приложения, а встроенные метатеги, которые инструктируют роботов не индексировать контент, не используются, то в индексе могут оказаться такие веб-страницы, которые не должны были там оказаться.
Допустим, вы владелец интернет-магазина. Изначально мета-теги и robots.txt были настроены правильно и ничего лишнего в выдачу поисковиков не попало. Потом вы решили изменить или добавить новый функционал к магазину. Суть его в том, что зарегистрированный покупатель из своего личного кабинета может просмотреть информацию о своих прошлых покупках, такую как дата заказа, наименование товара, адрес доставки, номер телефона покупателя, способ платежа и так далее, то есть то, что не должны видеть посторонние люди и тем более это не должно попасть в выдачу поисковиков. Но вот правильно настроить магазин после этого забыли. Результат может быть таким, как на скриншотах ниже:
Пример 1.
Пример 2.
Тот факт, что такие веб-страницы в принципе доступны для просмотра неаутентифицированным юзерам — тема другого раздела, до которого нам еще далеко. Но то, что они оказались в выдаче гугла — это результат неправильной настройки robots.txt и тегов meta в html-страницах.
Вообразим другую ситуацию. Вы решили обновить свой сайт, а старую версию сайта временно разместили по адресу old.mysite.ru. Через какое-то время старую версию вы удалили окончательно, и больше не переживаете за нее, а зря и вот почему:
Пример 3.
В кэше поисковых систем может быть сохраненная копия некоторых страниц. Злоумышленник, вероятно, изучит их и найдет там старые сообщения админов, емайлы, которые вы хотели бы скрыть, или еще что-нибудь интересное.
В данном случае ничего опасного нет, не переживайте
но для примера сойдет.Мы использовали прямой метод получения информации о цели. А что же с косвенным?
Представьте, что разработчики вашего интернет-магазина для удобства использовали какой-нибудь git-репозиторий, на который они выложили весь исходный код магазина и по какой-то причине, уже не зависящей от вас, репозиторий был проиндексирован поисковиком. Таким образом в руках злоумышленника может оказать информация о структуре вашего сайта, что сильно поможет ему при дальнейшем поиске уязвимостей.
Так же в поиске нужной информации вам могут помочь приожения, которые делают архивные копии сайтов со всего интернета, к примеру
Ссылка скрыта от гостей
.Рассмотрим еще один кейс с примером. Мы тестируем сайт, о владельцах которого нам известно мало или неизвестно ничего. На сайте находим такую информацию:
Пример 4.
UK Registered Company Number — меня заинтересовал этот идентификатор. Не знаю, что это, наверное что-то типа нашего ИНН. После быстрого гугления находим сайт, на котором по данному номеру можно получить некоторые данные о компании и владельцах:
Пример 5.
В результате имеем два имени, даты их рождения и адреса. Такая информация может пригодиться при подборе паролей к административным интерфейсам. Кроме того, имея эти данные мы можем поискать другие веб-приложения, принадлежащие тем же людям.
Ищите и обрящете. Мало ли, что попадет в гугл и как это "что" вам поможет далее.
Подведение итогов. Как тестировать:
С помощью поисковых систем попытайтесь найти:
- файлы конфигурации, логи и информацию о структуре целевого приложения
- сообщения админов сайта и других ключевых лиц
- логины и пароли пользователей
- тексты сообщений об ошибках
- тестовые, промежуточные, старые версии сайта
Изучите и используйте специальные операторы поисковых систем, которые будете использовать при тестировании. Вот, например, хорошая статья на Хабре про поисковые операторы Гугла. Не ограничивайтесь Гуглом, поскольку другие поисковые системы могут выдавать другие результаты поиска. Рассмотрите возможность использования следующих поисковых систем:
Baidu
binsearch.info
Bing
Duck Duck Go
ixquick/Startpage
Yandex
Shodan
DuckDuckGo и ixquick/Startpage обеспечивают некоторую анонимность для пентестера. Shodan выполняет поиск по устройствам или как говорят сегодня, поисковик по интернету вещей. Google имеет полезный оператор «cashe:».
В этом списке должен еще быть поисковик PunkSpider, но у меня он почему-то ни разу не открылся.
В ходе поиска задействуйте свою фантазию и терпение и тогда вам обязательно повезет
