Предлагаем снова поговорить о безопасности данных в веб-приложениях. Пользовательские данные — это драгоценный ресурс, утрата которого сулит целый ряд последствий с варьирующейся степенью серьезности. Но в очередной раз читать про пароли или рассматривать классические фишинг-примеры большинству пользователей будет скучно — этой информации в сети предостаточно. Поэтому сегодня мы расскажем вам несколько нетипичных историй, с которыми пришлось столкнуться нашим экспертам.
Немного теории
Начнем конечно с определения того, какие данные считать конфиденциальными. OWASP причисляет к ним пароли, номера кредитных карт, медицинские записи, личную информацию и бизнес-секреты. Помимо этого, за списком чувствительных данных следует обращаться к законам и отраслевым постановлениям тех регионов, откуда к вам могут прийти пользователи. Если речь о России, нужно заглянуть в Федеральный закон РФ № 152-ФЗ «О персональных данных», а в случае европейских пользователей, например, в Общий регламент ЕС по защите данных (GDPR) или в закон Великобритании о защите данных (DPA), которые регулируют использование персональных данных.
В любом случае, идем, изучаем требования и понимаем, какие данные пользователей мы обязаны содержать в целости и сохранности. Кстати, помимо этого есть еще и бизнес-требования. Закон может не требовать от вас применять строгие меры в отношении конфиденциальных данных, которые приложение создает или хранит для своих пользователей, но нарушение сохранности этих данных все равно нанесет вред вашим пользователям и, соответственно, вашей репутации.
В качестве конфиденциальных данных, хранящихся в приложениях, можно рассматривать следующее:
- Большинство пользовательских данных. Здесь, впрочем, нужно сделать оговорку: ваши данные, доступные всему интернету, например имена пользователей, которые мы и так видим где-нибудь в чате, могут не быть конфиденциальными).
- Данные приложения (такие как идентификаторы сеанса и ключи шифрования), которые помогают защитить данные пользователя от раскрытия.
Время удивительных историй
Давайте обсудим некоторые из наиболее распространенных уязвимостей, которые в нетривиальном виде наши специалисты встретили на практике. Суть уязвимостей не меняется, это все тот же список OWASP, но рассказ о таких случаях поможет взглянуть на безопасность приложений под другим углом.
Ищем старые версии
Различных чек-листов по безопасности веб-приложений в сети вагон и маленькая тележка. Но, как показывает практика, за всем уследить нереально. Особенно когда речь заходит об использовании старых версий компонентов в большом проекте. Так, однажды на сервисе, использующем подменные номера телефонов, было найдено старое семейство API, где номер еще не скрывался. Подменные номера — хорошая услуга, позволяющая скрыть реальный номер продавца с доски объявления. Однако, если внимательно изучить отправляемые запросы, найти документацию (или самим угадать нужные методы), то можно было сформировать запросы к старому API и получить через него подлинные номера пользователей.
В другом случае старый API привел к конкретным денежным потерям. В ходе расследования серьезной проблемы безопасности выяснилось, что один и тот же уязвимый метод API использовали не только ценные клиенты, но и нехорошие люди, тайно выводящие средства со счетов. Руководству пришлось принять риски — доход значительно превышал убытки, и было принято решение повременить с заменой уязвимого API.
Вполне возможно, что к более старым версиям компонентов приложения не будут применяться все актуальные политики безопасности, поэтому так важен процесс своевременного внедрения обновлений.
Смотрим шире на процессы
Проблемы больших проектов на этом не заканчиваются. Часто можно встретить бреши в безопасности из-за банальной несогласованности процессов. Проиллюстрируем примером: на одном из сервисов в чате с техподдержкой пользователи могли отправить вместе с жалобой номер карты, привязанной к сервису. По требованиям службы безопасности этот номер требовалось скрывать от сотрудников техподдержки. При более детальном изучении выяснилось, что номера карт в чате и правда маскируются, но при этом в ответе от сервера был ряд скрытых полей, которые в чат не подставлялись, но в трафике были видны. Если какие-то данные должны быть скрыты, оповестите об этом и фронтенд, и бекенд.
Лишнего не болтаем
Аналогичная проблема несогласованности процессов была найдена в функциональности сброса забытого пароля. После ввода логина (в данном случае — адреса электронной почты) сайт уточнял, куда отправить пароль: на почту или на привязанный номер телефона. Если был выбран второй вариант, то на странице появлялось оповещение с наполовину скрытым номером телефона. А вот в HTTP-ответе от сервера номер отображался целиком. Так можно было собрать целый список из пар “почта-номер телефона”. Раскрытие-с.
Кстати, к разговору о функционале сброса пароля. Если при реализации функционала регистрации только единицы забывают использовать общее предложение “неправильный логин или пароль”, то при восстановлении пароля информацию о наличии того или иного логина в системе раскрывают гораздо чаще. Конкретные ответы от сервера, подтверждающие наличие записи в системе, позволяют составить список пользователей и порой успешно использовать его в дальнейших атаках (фишинг, password spraying и т.д.). Но не только явные сообщения раскрывают информацию, вывод можно сделать по таймингу (например, таким страдали старые версии OWA — веб-клиента для доступа к Microsoft Exchange) или телу ответа.
Не храним лишнее
Существует хорошая практика — хранить только то, что действительно необходимо. Так, на неком сайте каждый раз, когда система отправляла email пользователю (например, при регистрации, анонсе мероприятий и т.п.), все сообщения записывались в лог. Этот лог на сайте был доступен, внутри хранились непосредственно текст сообщений, фамилия и имя пользователей, а также их почта. Интересно, что многие утилиты для поиска директорий данный файл не находили. Так как его размер был огромен (несколько ГБ), утилиты просто не могли дождаться, пока он скачается, и пропускали его. Но, перепробовав несколько вариантов утилит, аудиторы в конце концов добились своего.
В данной истории, помимо того, что в лог записывались избыточные данные, так еще и доступ к ним никак не был ограничен. Это, как ни парадоксально, далеко не редкий случай. Здесь стоит снова вспомнить ряд громких случаев (например, раз, два, три), когда утекали довольно серьезные объемы данных с Elasticsearch серверов.
Ну, не будем о грустном. Просто не забывайте правильно использовать авторизацию там, где она необходима.
Дружим с логикой
И все же самой распространенной болячкой, позволяющей утекать пользовательским данным, являются небезопасные прямые ссылки на объекты (Insecure Direct Object Reference, IDOR). В подтверждение расскажем две неклассические истории.
Обычно IDOR подразумевает чтение информации по идентификатору, минуя авторизацию или проверку прав. Но есть случаи, когда заполучить чужие данные возможно, отправив запрос на создание записи с уже существующим в системе идентификатором. Часть старых данных по этому идентификатору перезапишется, но остальные данные теперь будут доступны новому пользователю (и станут недоступны предыдущему — сменится хозяин).
Изначально в доступе к чужим данным будет отказано, но плохая реализация, позволяющая пользователю влиять на идентификатор объекта, пробивает огромную дыру в безопасности данных. Все идентификаторы объектов должны генерироваться на стороне бекенда.
В другом случае IDOR был найден при просмотре транзакций. В HTTP-запросе передавались три параметра:
POST /api/get_transactions HTTP/1.1
Host: example.com
GT|2315486|2315488|40117812222030001111, где 2315486 – идентификатор пользователя,
2315488 – идентификатор карты,
40117812222030001111 – номер счета.
На первый взгляд, перебрать 3 значения (34 цифры) не представляется возможным за обозримое время. Но, как выяснилось впоследствии, номер счета (40117812222030001111) в запросе можно было опустить: запрос все равно оставался валидным, как и ответ. Соответственно, оставалось только два числа для подбора — идентификатор пользователя и идентификатор карты.
Далее оказалось, что первое значение (идентификатор пользователя) может быть любым, например 1111111, но обязательно такого же размера, как идентификатор карты (7-значное число). Соответственно, параметр GT из 34-значного числа превратился в 7-значное, а перебрать его не составляет труда (в системе также отсутствовало ограничение на количество запросов от пользователей). В итоге, чтобы получить информацию о транзакциях, достаточно было знать только идентификатор карты (или перебрать его значение).
Уязвимости IDOR в целом не редкое явление, но чаще всего они встречаются в веб-приложениях со сложной структурой. Как и другие логические уязвимости, их довольно сложно выявить с помощью сканеров кода.
Еще раз всё проверим
Завершим наш рассказ случаем в онлайн-магазине, где использовались веб-сокеты. При оформлении заказа в системе для него генерировался ID, и пользователь подписывался по этому ID на все обновления касательно заказа. Но, как выяснилось позже, существовала возможность отправить подобный запрос “на подписку” не с конкретным ID, а с символом подстановки “*” на его месте. В результате можно было заполучить информацию обо всех заказах пользователей (с ФИО, адресами, телефонами и прочей сопутствующей информацией).
Заключение
Мы уверены, что подобных, а порой и куда более зубодробительных историй в практике специалистов ИБ предостаточно, но не всегда получается ими поделиться с сообществом. Обычно такое можно услышать в приватной беседе за кружечкой чая. И все же, делиться подобными случаями (обезличенно, конечно) — крайне полезная практика как для сообщества, так и для разработчиков. Поиск уязвимостей — это своего рода искусство мыслить иначе. Давайте вдохновлять друг друга.
