Как решить проблему уязвимостей бизнес-логики? Поломать приложение еще до написания кода

Всем привет. Меня зовут Нияз Кашапов, я AppSec Lead в СберМаркете. Улучшаю процессы безопасной разработки уже более 5 лет. Начинал карьеру в финтехе, где занимался безопасностью кода, фич и бизнес-процессов в онлайн-банкинге. А сейчас продолжаю начатое в одном из самых быстрорастущих игроков на рынке e-com.
Думаю, у многих в практике встречалась уязвимость, которую просто так не пофиксить — ведь она заложена глубоко внутри разрабатываемого решения, обвешана кучей зависимостей и требует полного ребилда самого решения. Чаще всего такие уязвимости остаются в проде навсегда и удерживаются от «падения» множеством костылей. Возникает резонный вопрос: «Как они возникли?» Чаще всего ответ — «Так исторически сложилось», а истоки проблемы давно забыты. Боролься с таким лучше превентивно, а как это сделать — попробую рассказать в этой статье.
Поговорим о том, как избегать ситуаций, когда уязвимость заложена на уровне архитектуры или бизнес-процесса и её исправление может стоить множество человеко-часов. Разберемся, когда фича становится багом и как прорабатывать архитектуру сервисов, не создавая дыры безопасности.
Читать далееИсточник: Хабрахабр
💬 Комментарии
В связи с новыми требованиями законодательства РФ (ФЗ-152, ФЗ «О рекламе») и ужесточением контроля со стороны РКН, мы отключили систему комментариев на сайте.
🔒 Важно Теперь мы не собираем и не храним ваши персональные данные — даже если очень захотим.
💡 Хотите обсудить материал?
Присоединяйтесь к нашему Telegram-каналу:
https://t.me/blogssmartzНажмите кнопку ниже — и вы сразу попадёте в чат с комментариями