Наталия Баранова

Если вы начинающий разработчик и создаете свой пет-проект, легко увлечься бэкендом и фронтендом, а на ИБ сил уже не останется. Даже если проект совсем небольшой и там, казалось бы, защищать-то особо нечего, злоумышленники всегда найдут дыры в безопасности. Взломать незащищенный сайт или приложение легче, чем кажется. Сразу уточним, что этот кейс — разбор пентеста пет-проекта одного из фронтенд-разработчиков. Проект не является частью продуктовой линейки Selectel. Также заранее заверим: все команды, которые развивают облачные продукты Selectel, придерживаются лучших практик информационной безопасности. В нашем отделе информационной безопасности мы, помимо пентеста критичных для бизнеса систем, также помогаем коллегам оценить защищенность их небольших проектов, когда те к нам обращаются. Кратко о приложении В Selectel мы любим давать вещам вторую жизнь. Батарейки — сдаем, контейнеры и одежду — тоже, чтобы хоть немного помочь природе. С мебелью та же история: у каждого предмета есть свой регламентированный срок жизни, но часто он истекает, а стол или стул все еще выглядят прилично. Просто выбросить? Не наш метод. Так родилась идея: вместо свалки — продавать мебель по приятной цене коллегам. Заходим на сайт — и нас встречает страница с доступными столами и стульями. Все миленько, аккуратненько. Если какой-то предмет привлек внимание, можно зарегистрироваться и вступить в розыгрыш — вот такой необычный мини-игровой элемент. После этого админ «крутит барабан», и счастливчик получает уведомление: вещь теперь его (если заплатит). Все выглядит просто и понятно, как дважды два. С точки зрения пользователя процесс кажется максимально прозрачным и легким, но на самом деле все куда интереснее. Уже на этапах регистрации, голосования за понравившийся предмет и хранения пользовательских данных проявились слабые места: в логике приложения, проверке прав и обработке информации. Именно эти тонкости мы разберем дальше — как раз те моменты, где маленький проект для разработчика превращается в большую работу для пентестера. Как проводим пентест Как правило, для меня пентест начинается с самого простого — «протыкивания» интерфейса: кликаю все кнопки, пробую все формы, изучаю поведение приложения как обычный пользователь. Это помогает быстро заметить необычное поведение, ошибки в UI или очевидные обходы логики. Если по результатам этого «прощупывания» ничего не всплыло — перехожу к более формальному осмотру. В основе нашей методики — рекомендации WSTG (OWASP Web Security Testing Guide). По сути, это наш внутренний чек‑лист, но с дополнительными наборами распространенных тест‑кейсов, которые я прогоняю для каждого веб‑приложения. В чек‑лист входят пункты по аутентификации и авторизации, управлению сессиями, валидации ввода, хранению данных, контролю доступа, защите от CSRF/XXE/SQLi/XSS и т. д. Параллельно «катаю» автотесты и вручную прогоняю критичные сценарии. Например, для данного приложения это регистрация, авторизация, голосование/розыгрыш, получение уведомлений — а если проще, то все, что используют пользователи. Пентест у нас двухраундовый, и это не потому что мы любим усложнять себе жизнь. После первого круга разработчики правят найденные баги, а чтобы убедиться, что фиксы работают и не порождают новых бед, мы бьем по системе еще раз. Почему это важно? Потому что исправления нередко закрывают лишь часть уязвимости или создают побочные эффекты. Таким образом, две итерации позволяют пройти полный цикл: нашли → исправили → проверили → закрыли задачу или вернули на доработку — и сделали это корректно. Результаты первого пентеста Первый пентест выдал несколько критичных проблем. Ниже я разберу только те, у которых был наибольший импакт. Критичность выявленных проблем — Critical. Высокие риски, выход в прод при таковых не рекомендован. — Moderate. Средние риски, выход в прод возможен при определении сроков устранения. — Notice. Низкие/отсутствующие риски, для информации. 1. Участие и отказ от участия за других пользователей Идентификаторы: CWE‑639 — Authorization Bypass Through User-Controlled Key, CWE‑285 — Improper Authorization. Эндпоинты «участвовать/отказаться» принимают запросы без аутентификации и слепо доверяют id/userId из тела или URL — то есть можно подменить чужой id и проголосовать или удалить голос от имени другого пользователя. Для механики голосований и розыгрышей это означает одну простую вещь: результаты можно фальсифицировать, а доверие пользователей — подмять под себя. Proof of Concept (PoC) 1. Как думаете, получится ли у меня получить id всех проголосовавших? Конечно, получится. Отправляем request: И получаем response: Здесь можно видеть id всех участников голосования, а также дату и время, когда они голосовали. В этом ответе мой userId — xfbz5c0o2c31b4b. 2. Проголосуем за другого пользователя (сервер принимает POST без токена). Request: Видим, что сервер создает/подтверждает запись от имени txfh2yo85343cyy — нет проверки авторства. 3. Попробуем удалить голос другого пользователя. Для этого используем метод DELETE и подменим id в URL. Request: Response: Запись удалена — операция прошла без авторизации и проверки владения. Вывод простой: приложение не проверяет авторство операций и полагается на данные, пришедшие от клиента, а клиент легко может их подделать. Рекомендации Требовать аутентификацию (токен/сессия) для всех операций изменения состояний (POST/DELETE/PUT/PATCH). Извлекать userId только из токена/сессии и игнорировать userId, присланный клиентом. Проверять на сервере, что удаляемая или изменяемая запись принадлежит текущему пользователю (owner‑check). 2. Раскрытие данных пользователей без аутентификации Идентификаторы: CWE‑200 — Exposure of Sensitive Information to an Unauthorized Actor, CWE‑284 — Improper Access Control, CWE‑287 — Improper Authentication. API отдает профили пользователей без аутентификации. Зная id, можно запросить чужой профиль (даже админа) и увидеть его данные, а также историю действий. Последствия очевидны: утечка персональных данных, служебных email, возможность легко выявлять администраторов и создавать почву для фишинга или перебора логинов. PoC: получим профиль администратора. Request: Response: 2. А как вам идея собрать список всех email пользователей? Это легче, чем кажется. Request: Response: 3. Может, история выбора предметов конкретного пользователя будет скрыта? Нет. Request: Response: Рекомендации Закрыть эндпоинты авторизацией (JWT, SSO или аналог). Возвращать только минимально необходимый набор данных — ничего лишнего в ответах. Проверять права на сервере, чтобы убедиться, что текущий пользователь действительно может видеть конкретную информацию о чужих профилях. 3. Обход ограничения на уникальность email Идентификаторы: CWE‑694 — Use of Multiple Resources with Duplicate Identifier, CWE‑20 — Improper Input Validation. Приложение позволяет регистрироваться только с почтами, которые принадлежат домену selectel.ru. Кроме того, придется пройти верификацию учетной записи, поэтому чужой адрес почты использовать нельзя. Но я заметила, что сайт не нормализует email при регистрации: символ «+» и последующие фактически игнорируются у многих почтовых провайдеров, поэтому на один реальный ящик можно завести несколько аккаунтов вроде example@selectel.ru и example+user@selectel.ru. В контексте розыгрышей — это бесплатный баг в системе: дополнительные аккаунты легко использовать для накрутки голосов и других мошенничеств. Рекомендации Нормализовать email при регистрации (привести к нижнему регистру и убрать «+»‑теги). Требовать верификацию подтвержденного адреса и по возможности перейти на SSO, чтобы исключить дублирование аккаунтов. Итоги первого пентеста Вкратце: три главные проблемы — возможность голосовать/удалять голоса за других, публичный доступ к профилям и почтам, а также обход уникальности email — в сумме дают понятный набор рисков: фальсификация розыгрышей, массовый сбор персональных данных и простая накрутка через дубли‑аккаунты. Причины — банальны и одновременно опасны: сервер доверяет клиенту, валидация поверхностная, а авторизация мягче ватного шарика. Простые правки — требование аутентификации для критичных операций, получение userId только из токена/сессии, нормализация email и скрытие приватных полей в API — закрывают основные входы для атак. Но фиксы — спойлер — меняют логику приложения и иногда рождают новые нюансы. Ниже — разбор второго пентеста: сданные уязвимости были исправлены, но после доработки всплыли новые моменты. Результаты второго пентеста 1. Заведение пользователя-админа через скрытое поле 'isAdmin':true Идентификаторы: CWE‑285 — Improper Authorization, CWE‑269 — Improper Privilege Management. В запросе на регистрацию можно передать скрытое поле isAdmin — и это позволит любому пользователю получить права администратора. А с ними можно редактировать карточки товаров, выбирать победителей в розыгрышах, просматривать всех пользователей, менять их данные и творить прочие безобразия🙂 Передав ‘isAdmin’:true, получаем админа и идем смотреть, что нам теперь доступно. Давайте начнем с того, что поменяем цену на товар. Например, есть диван, который стоит 6 000 ₽: Отправим запрос на изменение его стоимости через админа (которым мы сделали себя сами) и получим очень приятную цену со скидкой — 0 ₽: Или провернем трюк с другим товаром. Давайте проведем честные выборы назначим победителя, ведь у нас есть для этого специальная кнопка: Чтобы убедиться, что победил наш кандидат, зайдем в его аккаунт и увидим подтверждение. Ради интереса выведем список всех пользователей, участвовавших в голосовании: И это лишь часть возможностей админа. PoC (получение прав админа): регистрация пользователя с установленным ‘isAdmin’:true. Успех, теперь мы — админ: После прохождения верификации почты приложение дает доступ к функциям админа. Еще одно подтверждение админских прав — получение ответа от сервера после успешной авторизации: PoC (редактирование карточки): Запрос на изменение стоимости товара: Цена успешно изменена: Рекомендации Убрать возможность регистрации с правами администратора — удалить поле isAdmin из клиентской части, чтобы оно не передавалось в API. Права админа назначать только через существующего администратора. Дополнительно сервер должен проверять все входящие данные и не доверять клиенту. 2. Возможность «накрутки» запросов на участие Идентификаторы: CWE‑639 — Authorization Bypass Through User-Controlled Key, CWE‑285 — Improper Authorization. Перехватив POST‑запрос, можно подменить id записи участия и проголосовать несколько раз за одно и то же соревнование, что делает накрутки и фальсификации тривиальными. PoC: отправляем запрос на участие, изменив значение поля id на любое уникальное. Выведем все записи розыгрыша мебели. Обратите внимание на разные записи, которые относятся к одной связке «мебель-пользователь»: Рекомендаци На сервере жестко ограничить количество голосов по схеме «не более одного голоса от одного пользователя на одно голосование» (проверять userId из токена/сессии, игнорировать userId из тела). Помимо прочего, важно добавить уникальные ограничения/индексы и rate‑limit на операции голосования. 3. Нет флага HttpOnly для куки pb_auth Идентификаторы: CWE‑200 — Exposure of Sensitive Information to an Unauthorized Actor, CWE‑79 — Cross‑Site Scripting (XSS). Токен в pb_auth хранится в куке без HttpOnly. Значит, любой XSS‑скрипт на странице может ее прочитать и унести сессию — а дальше действовать от имени жертвы. Это прямой путь к краже аккаунтов, утечке данных и массовым злоупотреблениям. Рекомендация — сделать cookie HttpOnly . 4. Токены аутентификации не отзываются после выхода из аккаунта Идентификатор: CWE‑613 — Insufficient Session Expiration. После логаута токен все еще живет и продолжает работать до своего истечения. Это значит, что если злоумышленник его перехватит, то сможет выдать себя за пользователя и действовать от его имени. Рекомендация: токен должен инвалидироваться сразу после выхода из приложения — аналогично тому, как это происходит при смене пароля. 5. Раскрытие валидных логинов и отсутствие защиты от брутфорса Идентификаторы: CWE‑200 — Exposure of Sensitive Information to an Unauthorized Actor, CWE‑307 — Improper Restriction of Excessive Authentication Attempts. Запрос на регистрацию охотно отвечает, какие логины уже заняты. Собрав список «живых» логинов, злоумышленнику остается только подобрать пароли. В отсутствие rate‑limit, капч и MFA это превращается в реальную угрозу компрометации учеток и кражи доступа. PoC: мы можем увидеть раскрытие существующего пользователя под формой входа. Или в ответе на запрос регистрации: С обнаруженным логином можем выполнить перебор паролей, потому что нет никакой защиты от брутфорса: Рекомендации: ответ формы регистрации должен быть одинаковым для всех случаев — например, как при сбросе пароля для суперпользователя (/api/collections/_superusers/request-password-reset), где всегда пишется, что письмо отправлено, независимо от логина. Чтобы защититься от брутфорса, можно добавить капчу, ограничение скорости запросов (rate-limiting) или полностью перейти на вход через SSO. 6. Yandex Webvisor собирает email пользователей Идентификатор: CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor. Ненастроенный Yandex Webvisor ловит все логины, которые пользователи вводят в формах регистрации и входа. Если кто‑то посторонний получит доступ к аналитике, это превратится в утечку чувствительных данных. PoC: Рекомендация — в настройках Webvisor запретить запись чувствительных данных, таких как логины, чтобы они не сохранялись и не могли попасть в чужие руки. 7. Отсутствует кнопка сброса пароля для обычных пользователей Идентификатор: CWE-640 — Weak Password Recovery Mechanism for Forgotten Password. У обычного пользователя должна быть возможность сброса пароля без знания старого, как это реализовано для админа через / _/#/request-password-reset. Сейчас же поменять пароль можно только через PATCH на /api/collections/users/records, зная старый пароль, что лишает пользователей стандартного механизма восстановления. PoC. Так выглядит сброс пароля на /api/collections/users/records с указанием старого пароля: При этом на входе нет знакомой кнопки «Забыл пароль»: Рекомендации Если вход по логину и паролю остается, добавить пользователям возможность сброса пароля без знания старого, а также реализовать функцию смены пароля в самом аккаунте. Внедрить двухфакторную аутентификацию (2FA) — и удобно, и безопасно (ну, почти). Заключение Вот такие дела: приложение тестировалось легко, а уязвимости оказались классическими — ровно те, что чаще всего всплывают в небольших проектах. Самое трудоемкое здесь, пожалуй, было аккуратно оформить результаты в отчет.