Привет, Хабр! Для любого сервиса главное — это клиент. Когда он уходит, становится очень больно. Вдвойне больнее, если сервисом пользуются боты вместо реальных людей. Но понять это бывает не так просто, особенно если боты — нейросети.
Хотим поделиться кейсом по обеспечению двух важных условий на проекте — качества и безопасности. Мы подключились к проекту крупного сервиса, внутри которого команда разрабатывала модуль авторизации и личный кабинет пользователей. От наших специалистов требовалось помочь с разбором бэклога и сокращением техдолга. Эта задача превратилась в увлекательное расследование — в итоге нам удалось распутать большой узел связанных проблем, которые начинались с несоответствий в логах. Забегая вперед — это были и разлогины пользователей, и запросы на восстановление доступа, брутфорс паролей, а главное — ботовая активность. А все вместе это влияло на общую доступность сервиса, и, соответственно, экономическую эффективность проекта. Поэтому было важно обнаружить и устранить корень проблемы, а не только последствия.
Материал будет полезен QA-специалистам, аналитикам, лидам и project-менеджерам.
С чего все началось
Для того чтобы постепенно уменьшать техдолг, в команде выделили в каждом квартале три периода длиной в неделю, во время которых специалисты занимались только разбором бэклога.
Для всестороннего погружения в проект специалисты брали в проработку разнообразные задачи. И заметили, что есть очень много тасок на правку логов (на проекте помимо различных мониторингов была реализована самописная система логирования). Однако баги, связанные с улучшением системы мониторинга или влияющие на корень проблемы, было сложно исправлять и проверять. Гораздо быстрее фиксились кейсы от техподдержки в виде жалоб пользователей.
Один из частых кейсов был таким — пользователь, начав логиниться, не мог этого сделать и обращался в поддержку. И хотя работали различные мониторы, где видны регистрации, авторизации и ошибки серверов, они не могли дать ответа.
Как решали (и что было дальше)
QA-специалисты вместе с аналитиком придумали выход: необходимо дополнить логирование шагов юзера, чтобы видеть все места, где ломается система. Мы хотели совместить похожие кейсы и так выявить корневую проблему.
После первых исправлений багов аналитик дал фидбек о том, что метрики растут и становятся похожими на правду, то есть шаги записываются — вероятно, мы на верном пути. Стали выдергивать из бэклога старые баги, влияющие на запись статистики и аналитики, и рекомендовали поправить в первую очередь именно их.
После первой и второй недель чистки бэклога техдолг сократился. Но, сюрприз, багов не стало меньше.
Техподдержка приносила странные и сложно воспроизводимые ошибки. Пользователи жаловались на взлом аккаунта или недоступность. Это происходило по разным причинам: либо не подходил пароль, либо при попытке авторизации происходила ошибка на стороне бэкенда, либо пользователя просто выкидывало из активной сессии. Аналитика показывала, что юзер начал входить на страницу логина, а дальше происходила магия, которая не отслеживалась, как должна была. Доля таких пользователей составляла почти пятую часть от всего количества.
Мы не понимали, в чем дело. Предполагали, что что наша статистика пишется неверно, либо QA не справляются с тестированием, либо разработчики постоянно затрагивают код, завязанный на логировании.
Все баги были плохо воспроизводимы, статистика по коду и по проверкам от QA – ровная. Вероятно, это какая-то аномалия.
Начались даже разговоры о том, зачем мы вообще правили эти логи. Ведь именно система логирования стреляла непонятными пиками на графиках и дашбордах проекта.
Но оказалось, это всё было не про нас!
ИИстина где-то рядом
Тогда наши QA-специалисты предприняли отчаянный шаг и вместе с аналитиком представили команде идею усовершенствования системы логирования.
Ключевой идеей было собирать полноценную запись логов поведения юзера на нашем сервисе. Мы подошли к этому вопросу из глубины. Для нас было принципиально важно залогировать любое действие пользователя, для того чтобы распутать аномальные по поведению ошибки.
Раньше на нашем сервисе логировались только критичные ошибки системы. По таким логам можно понять, что нашему сервису плохо. Но из-за чего и почему? Вопрос оставался открытым. Зачастую приходилось тратить много времени на разбор лога, чтобы понять корень проблемы.
Со временем система логирования «обрастала» новыми входными данными, и детализации стало больше. Но все равно эти записи не раскрывали сути проблем, а были лишь индикаторами, кричащими: «У нас что-то сломалось».
Что мы сделали? Настроили систему логирования так, что буквально по каждому пользовательскому сценарию мы собирали и прорабатывали различные кейсы. В результате кропотливых изысканий нам удалось не только построить подробную аналитику действий пользователя, но и увидеть изнутри, кто же орудует в нашей системе.
Истина оказалась в том, что это были боты. Сервис подвергался атакам с применением искусственного интеллекта. И мы убедились в этом, когда начали бороться с действиями злоумышленников.
Объем ИИ-атак с каждым годом растет во всем мире, что создает угрозу для безопасности данных. Для понимания масштаба не нужно ходить далеко — достаточно вспомнить сообщество OWASP. А мои коллеги создали чек-лист по безопасности IT-продукта с точки зрения кода.
С развитием ИИ риски только растут.
OWASP Top 10 — это стандартный документ для разработчиков и специалистов по безопасности веб-приложений. Он представляет собой широкий консенсус в отношении наиболее серьезных угроз безопасности для веб-приложений. Включает в себя:
Нарушение контроля доступа (Broken Access Control)
Возникает, когда нарушен доступ и некоторые ограничения для аутентифицированных пользователей
Сбои криптографии (Cryptographic Failures)
Возникает в приложениях, в которых не защищены должным образом конфиденциальные данные: данные банковских карт, имена, пароли пользователей и другое.
Внедрение кода (Injection)
Запрос или команда, которая применяется злоумышленником для вставки в интерпретатор через обращение к базе данных или, например, к LDAP (Lightweight Directory Access Protocol — «легковесный протокол доступа к каталогам»)
Небезопасный дизайн (Insecure Design)
Новая категория, которая появилась в рейтинге в 2021 году, посвящена рискам, связанным с ошибками проектирования и архитектуры приложения
Неправильная конфигурация (Security Misconfiguration)
Например, неправильно настроены разрешения для облачных служб, включены или установлены ненужные функции, учетные записи по умолчанию, обработка ошибок выявляет трассировки стека или другие чрезмерно информативные сообщения об ошибках для пользователей
Уязвимые и устаревшие компоненты (Vulnerable and Outdated Components)
Существует множество программных компонентов с открытым исходным кодом, а так же библиотек и фреймворков, доступных разработчикам с уязвимостями
Ошибки идентификации и аутентификации (Identification and Authentication Failures)
Проблемы с аутентификацией позволяют злоумышленнику использовать различные методы для получения контроля над любой учётной записью в системе. Проблема возникает из-за ошибок в управлении сеансом, что позволяет злоумышленникам взломать пароли, ключи безопасности и другое.
Нарушения целостности программного обеспечения и данных (Software and Data Integrity Failures)
Небезопасная десериализация (Insecure Deserialization) позволяет злоумышленнику удалённо выполнять код в приложении, подделывать или удалять сериализованные (записанные на диск) объекты, проводить атаки путём внедрения, повторного воспроизведения
Сбои регистрации и мониторинга безопасности (Security Logging and Monitoring Failures)
Неверное ведение журнала безопасности и неэффективная интеграция систем безопасности являются «открытой дверью» для злоумышленников и их манипуляций
Подделка запросов на стороне сервера (Server-Side Request Forgery)
Ошибки SSRF (server side request forgery — программный код, с помощью которого можно заставить уязвимое приложение сделать запрос на предоставленный URL). Подделка запроса на стороне сервера – это атака, которая позволяет отправлять запросы от имени сервера к внешним или внутренним ресурсам
Мы начали копать дальше и искать связанные проблемы.
Кейс №1. DDoS-атаки
Еще до полноценного внедрения самописной системы логирования команда столкнулась с атаками на сервер извне. Поступали жалобы, что пользователю приходится часто вводить свой пароль – его просто выбрасывает из активной сессии. Из-за особенностей инфраструктуры мы связали эти атаки с данным кейсом и не промахнулись.
Раньше это были DoS-атаки, которые легко подавлялись блокированием пакета по IP. Сейчас же шли именно DDoS-атаки, с которыми стало тяжело бороться из-за стремительного развития ИИ.
Основное различие DoS от DDoS
Cпособ технической реализации – DoS-атаки идут от одного источника, а DDoS проводится с множества устройств.
Во-первых, искусственный интеллект может быть использован для автоматической генерации атак.
Во-вторых, ИИ применяют для взлома различных устройств IoT, многие из которых не обеспечивают необходимый уровень безопасности. При использовании ИИ злоумышленник может получить доступ к большому количеству устройств IoT и использовать их в качестве ботнета для атак на другие системы.
Из-за того, что сетевые ресурсы (такие, как веб-сервера) имеют ограничения по количеству запросов, пропускной способности канала, под воздействиями атак извне может произойти полное прекращение работы веб-ресурса – «отказ в обслуживании» или DoS (Denial-of-service).
В некоторых случаях DDoS-атака может являться попыткой дискредитировать или разрушить бизнес: замедлить или остановить процессы продаж, обслуживания, информирования, атаковать SEO-позиции.
Как решали
Чтобы понять злоумышленника, мы стали действовать как он: собрали свою систему на основе ИИ для нагрузки наших серверов, сделали копии наших серверов, сымитировали атаки на наши движки и стали анализировать систему в момент их деградации. По итогам масштабного тестирования выявили множество кейсов, при которых нагруженный сервер выбрасывал пользователя из активной сессии. Это всегда бьет по бюджету, ведь каждый сервис заинтересован в том, чтобы активное время юзера было наибольшим. Так мы продвигались к решению следующей задачи.
Кейс №2. Спуфинг
Кроме того, злоумышленники использовали для предотвращения обнаружения спуфинг — вид взлома, при котором человек или программа пытаются получить несанкционированный доступ к системе или информации пользователя (в обход контроля доступа), украсть данные или распространить вредоносное ПО, успешно маскируясь под пользователя.
Спуфинг известен многим по применению в антидрон-системах. Для подавления дронов имитируется фейковый сигнал и происходит фальсификация навигационных координат, а также времени. Это может стать критичным для общей инфраструктуры.
Многие из вас встречались хотя бы раз с проблемами, вызванными некорректным временем на сервере, выполняющим ту или иную роль. Например, возможно некорректное формирование бэкапов, задержка в обработке запросов, некорректная интерпретация валидности сертификатов, ошибки аутентификации и авторизации.
Как решали
Сертификаты безопасности обеспечивают защищенный обмен данными внутри IT экосистем. Нет сертификата – нет уверенности, что данные не попадут в посторонние руки. Поэтому важно следить за сертификатами и вовремя их обновлять, иначе вся цепочка интеграций может рассыпаться. Часто бывает такое, что при неверном времени сервера сертификаты невалидны и приложение не работает.
Помимо этого, синхронизация требуется в системах мониторинга и управления с целью протоколирования возникающих событий и своевременного реагирования на них.
Вручную следить за всеми сертификатами практически невозможно, а главное, нецелесообразно.
Мы обошли эту уязвимость, настроив мониторинг, который вовремя предупреждает об истекающих сроках сертификатов.
Кейс №3. Брутфорс
Следующей проблемой стал брутфорс — метод взлома с помощью перебора паролей. Так как наша команда была ответственна за личный кабинет пользователей, в частности, за регистрацию и авторизацию, мы часто встречались с жалобами на взлом аккаунта. Для решения этой сложной проблемы тоже удалось найти инструменты.
В современных системах пользователь может зарегистрироваться по номеру телефона, email или логину. Казалось бы, огромный выбор это верное решение. В то же время это требует от разработки правильного построения архитектуры, системы обеспечения безопасности и конфиденциальности профилей.
Обнаружилось два типа кейсов со взломами:
Самый распространенный — с профилями, которые не имели двухфакторной аутентификации и состояли просто из логина и пароля. Нейронка спокойно проходила связку «логин — поле пароля» с помощью перебора.
На учетках с двухфакторкой пользователь сначала вводил смс или код с почты, а потом пароль. Боты, попадая на страницу подтверждения, автоматом отсеивались. Учетки без подключенной двухфакторки оставались в зоне брутфорса.
Очень старые профили с использованием email, которые давно были взломаны. Пользователи даже не знали этого, так как не заходили в эти почты и не привязывали к аккаунту дополнительные email или телефон. Часто это бабушки/дедушки, которые заводят почту-заглушку и забывают о ней.
В своей системе логирования мы хорошо видели, когда начинался брутфорс, но не могли со своей стороны ограничить доступ моментально. Ведь пользователь может ошибиться при вводе пароля, ему нужно дать возможность исправиться и зайти в аккаунт. Реагировать на данные действия в режиме онлайн сложно – это долго и дорого. Нужно менять подход в инфраструктуре.
Как решали
Итоговым решением стал уход от паролей в привычном понимании. Они остались, но используются в крайних случаях, когда у пользователя нет подтверждающего фактора владения — например, нет доступа к телефону или не ловит связь. Мы внедрили новый порядок подтверждения факторов владения. По сути это такая же двухфакторная аутентификация, но она быстрее, удобнее и безопаснее. Теперь не надо запоминать пароль и долго восстанавливать доступ при потере аккаунта.
Первое, что мы проработали — это подтверждение по смс. И здесь снова встретились с ИИ. Ранее, если пользователь привязывал номер телефона, мы применяли подтверждение по смс, а злоумышленники, понимая, что за каждую смс платит сервис, активизировали атаки в этом русле. Бюджет потек...
Тогда внедрили более жесткий лимит на повторные запросы.
Следующие факторы владения – это использование звонка сброса на номер абонента, push и применение проверочных кодов на email. Мы определили такую последовательность, чтобы минимально влиять на бюджет. Если у пользователя есть возможность получить push, в первую очередь стали давать ему именно этот вариант.
Помимо этого, мы подключили возможность авторизации с помощью встроенных в устройства технологий авторизации, к примеру Touch ID и Face ID и по приложению аутентификатору.
Кейс №4. Потеря доступа
Среди кейсов от пользователей встречались жалобы на потерю доступа, запросы на восстановление пароля, требования откатить обновления, из-за которых якобы неудобно пользоваться сервисом. Случай не уникальный, но нужно убедиться – даем ли мы доступ действительно тому человеку, кому принадлежит аккаунт? Может быть, откатить обновления просят для того, чтобы старые методы взлома или атак снова работали?
Подтвердить благонадежность аккаунта могут факторы владения – например, привязанный телефон пользователя. А как быть, если аккаунт не привязал его и хочет сделать это при восстановлении?
Как решали
Для решения этой задачи ввели верификацию аккаунтов на сервисе. Теперь логи активно анализируются при попытке перепривязки номера или почты. Удалось переработать систему восстановления паролей, и теперь во многих случаях в заявках на восстановление пароля возможно проверять фактор владения и автоматически возвращать доступ к аккаунту. Ранее это делалось вручную.
Хэппи-энд и результаты
За полгода работы на проекте и благодаря общим усилиям мы смогли не только проявить проблемные места, но и найти пути их решения. Ключевым фактором стало усовершенствование системы логирования.
Почти квартал мы потратили на закрытие первоочередных проблем и теперь реализуем новые фичи, которые помогают двигаться вперед, не боясь внешних воздействий. Нам удалось избавить проект от первопричины проблем, и это я считаю самым главным.
Количество багов уменьшилось, сейчас в бэклоге критов стало меньше на 80%, а мажоров — в пределах 40%.
Фичи, направленные на уменьшение потерь, очень хорошо «отрубили» ботов и сократили потери бюджета на десятки миллионов. При этом 2023-2024 году ожидается рост стоимости внутренних смс на 30%, а отправка за границу будет еще дороже.
У QA-команды появилась возможность заниматься не только фиксом багов, но и катить новые фичи и улучшать продукт. Мы упрощаем пользовательские сценарии, при этом увеличивая безопасность профилей и скорость их работы, используя минимальное вмешательство пользователя. Удалось автоматизировать тестирование 100% бэкенда и оптимизировать фреймворк для е2е-тестирования, перейдя на JS Playwright. Автотесты на нем прогоняются быстрее, чем на связке Java+Selenium.
Конечно, это не исчерпывающий список кейсов, и от всех угроз сложно защититься. Но подобрав правильный подход к тестированию безопасности нашего сервиса, команда готова противостоять внешним угрозам, даже с применением искусственного интеллекта.
В сухом остатке получаем:
снижение активности ботов
снижение количества кейсов от техподдержки
полный разбор бэклога
уменьшение техдолга
снижение количества багов
улучшение систем мониторинга
появление нового флоу авторизации
улучшение качества сервиса
снижение time-to-market
Бонус: как обезопасить проект от угроз с применением ИИ?
Для предотвращения угроз безопасности-IT проекта, связанных с развитием искусственного интеллекта, необходимо использовать современные средства защиты и мониторинга, а также строго соблюдать меры безопасности и проводить регулярные аудиты систем и приложений:
Необходимо выстроить процесс разработки, интегрируя безопасность в каждый этап SDLC. Это обеспечит целостный подход к безопасности приложения. Ведь когда ошибка обнаруживается на ранней стадии, ее можно устранить быстрее и с меньшими затратами.
Важно отслеживать результаты тестирования и разрабатывать метрики, которые будут отображать тенденции безопасности приложений. Хорошее тестирование безопасности требует выхода за рамки ожидаемого и мышления злоумышленника, пытающегося взломать приложение. Одна из причин того, что автоматизированные инструменты плохо справляются с тестированием на наличие уязвимостей, заключается в том, что автоматизированные инструменты не мыслят творчески. Для того чтобы найти эти кейсы, нужно не только покрыть большую часть проекта автотестами, но и создать имитацию воздействия ИИ или нейросети на наш сервис.
Для успешного тестирования web-приложений необходимо применять систематизированный подход, в котором тестировщик должен понимать все точки входа приложения (HTTP-заголовки, параметры, куки и так далее).
Необходимо определить возможные риски и уязвимости и подготовить план тестирования в соответствии ними.
Важно следить за шифрованием данных и избегать устаревших криптографических функций. Например, если сайт не использует TLS (transport layer security — протокол защиты транспортного уровня) на всех страницах или применяется слабое шифрование данных, то злоумышленник с помощью cookie перехватит сеанс пользователя.
Важно правильно тестировать конфигурации и не забывать про политики пользовательской безопасности. Проводить тестирование аутентификации, авторизации, управления сессией.
Регрессионное тестирование должно включать кейсы на SQL, PHP, ASP, SSI-инъекции, XSS, XSRF/CSRF, IDOR уязвимости.
Нужно проверять правильную обработку ошибок. Необходимо отдавать пользователю ошибки, не позволяющие определить, используется ли в системе данный номер/логин/email.
Не забывать про тестирование бизнес-логики и выполнять тестирование уязвимостей на стороне пользователя. Если в приложении используется компонент, имеющий уже известную уязвимость, он становится слабым звеном, которое может повлиять на безопасность всей системы. Разработчики часто не вникают в то, какие компоненты уже присутствуют в их приложениях от предыдущих специалистов.
Совершенствуйте систему логирования. Старайтесь залогировать все действия пользователя, учитывая нетривиальные действия.
Нужно фильтровать обращения пользователей на предмет владения аккаунтом. Если пользователи часто жалуются в службу поддержки на то, что не могут получить доступ — это могут быть боты. На случай, если учетную запись угнали или хотят угнать, нужно идентифицировать пользователей, нельзя по умолчанию реагировать так, будто это реальный владелец аккаунта.
Соблюдение этих пунктов дает возможность обеспечить сбалансированный подход, включающий несколько техник — от ручных обзоров до технического тестирования и комплексного тестирования CI/CD. И QA выполняет важную роль в достижении этой цели.
Спасибо за внимание!
Авторские материалы для разработчиков и QA-специалистов мы также публикуем в наших соцсетях – ВКонтакте и Telegram.
