Бизнес-логика
В этом разделе мы рассмотрим концепцию уязвимостей бизнес-логики и то, как они могут возникать из-за ошибочных предположений о поведении пользователей. Мы обсудим потенциальное влияние логических изъянов и как их эксплуатировать. Также вы сможете потренироваться на лабораторных работах, основанных на реальных багах. Наконец, вы получите общие рекомендации по предотвращению появления подобных логических изъянов в ваших приложениях.
Лабораторные работы
Если вы уже знакомы с основными концепциями уязвимостей бизнес-логики и просто хотите попрактиковаться в их эксплуатации на реалистичных, намеренно уязвимых целях, вы можете получить доступ ко всем лабораторным работам по этой теме по ссылке ниже.
Что такое уязвимости бизнес-логики?
Уязвимости бизнес-логики — это изъяны в проектировании и реализации приложения, позволяющие атакующему вызывать непреднамеренное поведение. Это потенциально дает возможность манипулировать легитимной функциональностью для достижения злонамеренной цели. Такие изъяны обычно являются результатом неспособности предвидеть необычные состояния приложения и, как следствие, неспособности безопасно с ними обращаться.
Логические изъяны часто незаметны для людей, которые специально их не ищут, поскольку они обычно не проявляются при нормальном использовании приложения. Однако атакующий может эксплуатировать поведенческие особенности, взаимодействуя с приложением не предусмотренными способами.
Одна из основных задач бизнес-логики — обеспечить соблюдение правил и ограничений, определенных при проектировании приложения или функциональности. В общих чертах, бизнес-правила диктуют, как приложение должно реагировать при возникновении конкретного сценария. Это включает предотвращение действий пользователей, которые негативно повлияют на бизнес или просто не имеют смысла.
Изъяны в логике позволяют атакующему обходить эти правила. Например, он может завершить транзакцию, не проходя через предусмотренный процесс покупки. В других случаях поломанная или отсутствующая валидация данных, предоставленных пользователем, может позволить произвольно изменять критичные для транзакции значения или отправлять бессмысленный ввод. Передавая неожиданные значения в серверную логику, атакующий потенциально может заставить приложение делать то, что оно не должно.
Уязвимости на основе логики могут быть чрезвычайно разнообразны и часто уникальны для приложения и его конкретной функциональности. Их выявление часто требует определенных знаний, таких как понимание предметной области или того, каких целей может добиваться атакующий в данном контексте. Это затрудняет их обнаружение автоматизированными сканерами уязвимостей. В результате логические изъяны — отличная цель для багбаунти-охотников и ручных тестировщиков в целом.
Как возникают уязвимости бизнес-логики?
Уязвимости бизнес-логики часто возникают потому, что команды проектирования и разработки делают ошибочные предположения о том, как пользователи будут взаимодействовать с приложением. Эти неверные предположения приводят к недостаточной валидации пользовательского ввода. Например, если разработчики предполагают, что пользователи будут передавать данные исключительно через веб-браузер, приложение может полностью полагаться на слабые клиентские средства контроля для валидации ввода. Их легко обойти с помощью прокси.
В конечном итоге это означает, что когда злоумышленник отклоняется от ожидаемого поведения пользователя, приложение не предпринимает соответствующих шагов, чтобы предотвратить это, и, как следствие, не справляется с ситуацией безопасно.
Логические изъяны особенно распространены в чрезмерно сложных системах, которые даже сама команда разработки не до конца понимает. Чтобы избежать логических изъянов, разработчики должны понимать приложение целиком. Это включает осведомленность о том, как разные функции могут комбинироваться неожиданными способами. Разработчики, работающие с большими кодовыми базами, могут не иметь глубокого понимания работы всех областей приложения. Человек, работающий над одним компонентом, может сделать ошибочные предположения о том, как работает другой компонент, и в результате непреднамеренно ввести серьезные логические изъяны. Если разработчики явно не документируют делаемые предположения, подобные уязвимости легко могут закрасться в приложение.
Каковы последствия уязвимостей бизнес-логики?
Воздействие уязвимостей бизнес-логики порой может быть достаточно тривиальным. Это широкая категория, и влияние сильно варьируется. Однако любое непреднамеренное поведение потенциально может привести к атакам высокой серьёзности, если злоумышленник сможет правильно манипулировать приложением. По этой причине странности логики желательно исправлять, даже если вы не можете понять, как их эксплуатировать. Всегда есть риск, что это сможет сделать кто-то другой.
В основе воздействия любого логического изъяна лежит функциональность, к которой он относится. Если изъян в механизме аутентификации, например, это может сильно повлиять на вашу общую безопасность. Злоумышленники могут эксплуатировать это для повышения привилегий или полностью обходить аутентификацию, получая доступ к конфиденциальным данным и функциональности. Это также расширяет поверхность атаки для других эксплойтов.
Изъяны логики в финансовых транзакциях очевидно могут привести к огромным потерям для бизнеса через кражу средств, мошенничество и т.п.
Также следует отметить, что даже если логические изъяны не позволяют злоумышленнику получить прямую выгоду, они всё равно могут позволить нанести ущерб бизнесу каким-то образом.
Какие есть примеры уязвимостей бизнес-логики?
Лучший способ понять уязвимости бизнес-логики — изучить реальные случаи и извлечь уроки из допущенных ошибок. На следующей странице предоставлены конкретные примеры различных распространенных логических изъянов, а также несколько намеренно уязвимых сайтов, чтобы вы могли самостоятельно попрактиковаться в эксплуатации этих уязвимостей.
Как предотвратить уязвимости бизнес-логики
Вкратце, ключи к предотвращению уязвимостей бизнес-логики следующие:
Убедитесь, что разработчики и тестировщики понимают предметную область, которую обслуживает приложение
Избегайте неявных предположений о поведении пользователей или о поведении других частей приложения
Вам следует определить, какие предположения вы сделали о состоянии на стороне сервера, и реализовать необходимую логику для проверки того, что эти предположения выполняются. Это включает проверку, что значение любого ввода является разумным, прежде чем продолжать.
Также важно убедиться, что и разработчики, и тестировщики способны полностью понимать эти предположения и то, как приложение должно реагировать в разных сценариях. Это поможет команде обнаруживать логические изъяны как можно раньше. Для этого команда разработки должна по возможности придерживаться следующих передовых практик:
Поддерживайте чёткие документы проектирования и потоки данных для всех транзакций и рабочих процессов, отмечая любые предположения, делаемые на каждом этапе.
Пишите код максимально ясно. Если трудно понять, что должно происходить, будет трудно заметить логические изъяны. В идеале, хорошо написанный код не должен нуждаться в документации для понимания. В неизбежно сложных случаях создание понятной документации критически важно, чтобы другие разработчики и тестировщики знали, какие предположения делаются и каково ожидаемое поведение.
Отмечайте любые ссылки на другой код, который использует каждый компонент. Продумайте любые побочные эффекты этих зависимостей, если злоумышленник манипулирует ими необычным образом.
Из-за относительно уникальной природы многих логических изъянов легко списать их на разовую ошибку из-за человеческого фактора и двигаться дальше. Однако, как мы показали, эти изъяны часто являются результатом плохих практик на начальных этапах создания приложения. Анализ того, почему логический изъян возник изначально и как он был пропущен командой, поможет вам выявить слабые места в ваших процессах. Внося небольшие корректировки, вы можете повысить вероятность того, что подобные изъяны будут пресечены в зародыше или обнаружены раньше в процессе разработки.
Last updated