Вы многое упускаете в своих пентестах!

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

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

Тестируйте все доступные платформы и клиенты

У компании может быть, например, веб-сайт, а также приложения для Android и для iOS. Если вы думаете, что все эти клиенты используют одни и те же эндпоинты при обращении к серверам компании, и что они эквивалентны по функционалу, вы ошибаетесь. Часть функций может быть доступна только в веб-сайте, или наоборот, только в приложении. Бизнес может считать, что веб-сайт, например, менее востребован, чем мобильные приложения, и поэтому часть фичей там будет отсутствовать. Поэтому обязательно исследуйте все клиенты, которые у компании имеются.

Более того, следует учитывать, что в зависимости от версии браузера или операционной системы, набор функций тоже может меняться, поэтому стоит хотя бы бегло глянуть на ресурсы компании в разных браузерах (или просто подменяя заголовок User-Agent на строки популярных браузеров, хотя это менее надёжно).

Стоит также помнить о том, что компания может предоставлять несколько мобильных приложений, покрывающих разные области бизнеса. Например, у компании Google есть приложения Google Ads и Google Analytics, каждое из них имеет свой набор функций и обращается к различным эндпоинтам. Как ни странно, разные приложения одной компании могут разрабатываться практически не связанными департаментами (или вообще быть отданными на аутсорс), что открывает возможности обнаружения интересных ошибок и уязвимостей. Например, приложение и сервисы для рекламы делаются одним департаментом, поиск - другим, а аналитика - аутсорсерами. При этом поиск показывает рекламу, а аналитика считает показатели рекламы в поиске. То есть, эти системы работают вместе. Если коммуникация между командами, разрабатывающими эти сервисы, недостаточная, то уязвимостей и логических багов будет сложно избежать.

Создавайте как можно больше аккаунтов

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

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

Все эти изменения сначала участвуют в экспериментах. Например, новую версию приложения получат только 10% пользователей, или новые функции в веб-сайте появятся только у 5%. Затем собираются метрики, и компания оценивает, как пользователи реагируют на изменение, увеличивается ли время пребывания на сайте или, скажем, количество покупок, не слишком ли нововведение дорогое с точки зрения ресурсов (CPU, потребление памяти и т.д.) и не замедляет ли оно работу сайта. Метрики пользователей из тестовой группы сравниваются с метриками из контрольной группы, которая нововведение не видит. После того, как компания получила достаточно сигналов, принимается решение раскатывать функционал на всех пользователей, или же эксперимент отключается, а изменение отправляется на доработку. Крупные компании одновременно проводят сотни экспериментов, которые длятся от нескольких дней до полугода.

И да, для бизнеса вы - просто набор метрик, приносящих деньги 😒

Идём дальше: после того, как компания решила включить новый функционал для всех пользователей, иногда создаётся так называемый holdout. Это небольшая группа пользователей (обычно 1%-2%), которая по-прежнему не будет иметь в своём приложении или интерфейсе веб-сайта включённый для остальных пользователей свежий функционал. Это требуется для контрольной проверки, чтобы бизнес мог убедиться в том, что доработка действительно полезна для пользователей и приносит деньги компании.

Гипотетический пример: маркетологи Pornhub предлагают добавить кнопку "Like" под видеороликами. Разработчики реализуют изменение, затем оно запускается на пару недель для 3% всех зарегистрированных пользователей.

Как веб-сайт выглядит на этапе эксперимента для большинства (97%) пользователей:

Как веб-сайт выглядит для 3% пользователей, попавших в тестовую группу эксперимента:

Далее, собранные метрики сообщают компании, что с такой кнопкой, пользователи стали продрочводить на 5% больше времени на сайте, что увеличило доход от рекламы на 1%. Также, из тестовой группы премиум-подписку купило на 2% больше пользователей. Изменение потребует от компании дополнительные 100 серверов для подсчёта и хранения данных о лайках. Взвесив все "за" и "против", компания решает запустить фичу для всех пользователей.

Я думаю, вы уже догадались, что вы едва ли станете участником достаточного количества подобных экспериментов, имея один или два аккаунта. А если не повезёт, то ваш аккаунт может даже стать членом holdout'а и не увидеть функционал, который другие (более удачливые) пентестеры уже давно тестируют. А это значит, что вы упустите некоторые эндпоинты или параметры запросов. Зарегистрировав (или найдя/купив) хотя бы десять (больше - лучше) аккаунтов, вы повышаете вероятность того, что какие-то из аккаунтов будут участвовать в различных экспериментах компании. Некоторые из них будут для вас очевидны (например, вы увидите изменения в интерфейсе веб-сайта, как в примере выше), а какие-то будут менее заметны (например, ваши запросы будут обрабатываться другим бэкендом, который компания в данный момент тестирует, и вы сможете увидеть небольшие отличия в ответах от сервера или отличающееся время обработки запросов). Я не уверен, что существует ПО, которое могло бы сравнить UI или содержимое веб-сайта или интерфейс приложения для разных пользователей. Но, как минимум, вы можете запустить софт, собирающий эндпоинты и их параметры, несколько раз подряд, задав Cookies различных пользователей для каждого прогона.

Если вам удалось обнаружить пару экспериментов, которые используют новые эндпоинты или параметры в имеющихся эндпоинтах, обязательно стоит проверить, как сервис среагирует на обращения к этим эндпоинтам/параметрам из-под аккаунта, не входящего в тестовую группу эксперимента.

Помимо экспериментов, компании иногда раскатывают новый функционал, например, сначала на 1% пользователей, потом на 10%, потом на 50%, и потом уже на всех остальных. Это может делаться с целью защитить бизнес от проблем. Если что-то пошло не так, то проще отключить неудавшееся обновление у 1% пользователей. Это также уменьшает потенциальные риски и потери (инвесторам будет легче среагировать на новость "Твиттер упал у 1% пользователей", чем на "Твиттер глобально недоступен, компания экстренно исправляет проблему"). Это ещё одна причина использовать побольше аккаунтов во время теста.

Создавайте аккаунты с разных IP-адресов и регионов

Помимо создания нескольких аккаунтов с одного и того же IP-адреса, стоит задуматься о регистрации аккаунтов с разных регионов. Это актуально в случае, если компания достаточно крупная и ведёт бизнес в разных странах (или в нескольких регионах одной страны).

Часто компания, когда готова включить новый функционал для пользователей (уже после того, как все эксперименты завершены), делает это сначала в каком-то конкретном регионе или стране. Например, новые функции, касающиеся ИИ, в продуктах Google или Meta сперва были активированы только в США. В некоторых других странах они появились только через несколько месяцев. Это может быть связано с тем, что в США законы о защите персональных данных выполнить проще, чем в Европе, где есть более жёсткий GDPR.

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

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

Периодически повторяйте тестирование

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

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

Это такой своеобразный Continuous Penetration Testing (CPT) вручную. Если можете и есть желание автоматизировать какие-то тесты, то вам это только на руку.

Обращайте внимание на соглашения и настройки

Вы, вероятно, не обращаете особого внимания на то, что после регистрации вас регулярно просят принять какие-то опциональные Cookies или соглашения. Вы просто их принимаете либо отклоняете, а потом приступаете к тестированию. Делая это, вы потенциально теряете часть багов.

Стоит делать тест функций, на которые эти соглашения могут влиять, в трёх состояниях: в аккаунте с принятыми соглашениями, в аккаунте с отклонёнными соглашениями, и в том аккаунте, где решение по соглашениям вами принято не было (если такое состояние допускается). Допустим, веб-сайт компании запрашивает разрешение использовать ваши личные данные на каком-то другом ресурсе компании, или с какой-то целью, которая опциональна и не обозначена в обязательной политике конфиденциальности. Пока вы не приняли это соглашение, стоит проверить, действительно ли на другом веб-сайте отсутствуют данные вашего аккаунта, и действительно ли на том веб-сайте вы не можете выполнить какие-либо действия. Точно ли опциональная функция недоступна для аккаунта, пока соглашения не принято? Если вы видите какое-то несоответствие, то это серьёзный юридический риск для компании, особенно ведущей бизнес в Европе. Помимо юридической стороны вопроса, этот функционал просто может быть реализован с ошибками, которые вы сможете проэксплуатировать (например, когда одна часть кода учитывает факт принятия соглашений, а другая часть - нет).

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

Вот пример опционального соглашения от Gmail. Как видно, можно отказаться, но потом снова при желании включить этот функционал в настройках:

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

Эпилог

Итак, для достижения максимального покрытия вашего теста, создавайте побольше пользователей с разными IP-адресами в различных регионах. Регулярно проводите повторное тестирование ресурсов компании, если у вас нет более срочных или выгодных программ багбаунти. Тестируйте на всех доступных платформах и клиентах, и обращайте внимание на такие мелочи, как опциональные соглашения.

Удачи и побольше ценных находок!