Разбираем принятый код — с чего начать ревью по OWASP Top 10?

Для ручного поиска отлично подходит греп по паттернам: 1) вызовы БД с конкатенацией переменных прямо в запросе, 2) ключи и секреты в открытом виде, 3) блоки перехвата ошибок, которые выплевывают наружу клиенту системные трейсы. Поиск по этим паттернам займет всего пару часов.

Когда мы принимали портал схожего масштаба, при ручном разборе за пару дней нашли 5 разных дыр в авторизации. Автосканеры их вообще не увидели, потому что понять, какие данные кому положено отдавать, может только человек, читающий бизнес-логику.

Сначала проверьте зависимости сторонних библиотек проекта. Запустите встроенные команды аудита безопасности в вашем пакетном менеджере и обновите пакеты с известными уязвимостями. Чаще всего самые большие дыры от аутсорс-агентств остаются именно из-за старых библиотек.

Двум разработчикам, которые не писали этот код, очень тяжело обезопасить чужую архитектуру чисто по чеклисту OWASP. Если время поджимает, сфокусируйтесь строго на правах доступа и запросах к БД, не закапывайтесь в сложную криптографию.

особенно проверьте смену id в url — можно ли так залезть в чужой заказ... галеры на бэке про эти проверки доступа постоянно забывают

edit: исправил несколько опечаток.

На этапе заключения договоров с крупными логистическими клиентами требование предоставить независимый отчет об аудите безопасности — обычная практика. Ваша внутренняя проверка укрепит систему, но юридически внешний аудит она не заменит.

Архитектура мультиарендная (multi-tenant)? То есть все клиенты сидят в одной базе данных? Если да, то главным фокусом ревью должна стать изоляция данных, чтобы один клиент ни при каких условиях не получил доступ к таблицам другого.

Для небольшой команды это может выглядеть пугающе, но пошаговый проход по гайдам OWASP как по чеклисту отлично прокачивает инженерное видение. Отлавливая баги в бизнес-логике, вы сделаете архитектуру в разы устойчивее.

Дешевый на вид путь обычно выходит дороже в итоге. Доступность резервной копии в той же сети и под той же учетной записью делает ее частью цели атаки.

Очень актуальная тема. Если не зафиксировать это письменно с самого начала, потом возникнут споры.

Пишите, если есть вопросы, отвечу по мере возможности.

Частично согласен, частично нет. Большая часть потерь времени копится на задачах, ожидающих согласования.

Позвольте подвести итог сказанному выше. Ошибка, сделанная на стороне owasp топ 10 обзор кода, обычно исправима, но дорого.

Оставлю как заметку, пригодится.

Есть момент который я не понял. Если путь уведомления длинный уведомление не приходит; а не пришедшее уведомление — это поздно обнаруженный инцидент.

То, что делают все, не значит что это правильно. Удачи.

Здесь есть ловушка, не могу промолчать. Люди защищают не процесс а привычку. Сопротивление идет оттуда.

Проверено опытом.

Посмотрю с другой стороны, я на стороне поставщика. Не полагайтесь на одну меру защиты; действуйте слоями.

Пытаться сделать это в одиночку — самый дорогой путь. Я бы пошел этим путем.

сохранил.

В целом верно, но один момент упущен... Прежде чем принимать решение посмотрите какие данные у вас есть.

Если напишете результат здесь, это поможет и другим.

Именно так. Больше всего времени у нас уходило на то, что было непонятно, кто принимает решения.

Пытаться сделать это в одиночку — самый дорогой путь.