Основы информационной безопасности

Компания Y предоставляет комплексное веб-приложение в сфере электронной коммерции Necommerce. Компания недавно столкнулась с массовой утечкой данных о своих пользователях и их покупках. “Брешь”, через которую произошла утечка, вроде как устранили.Саму разработку приложения компания Y заказывает у подрядчика (фирмы-разработчика).Поскольку своих специалистов по информационной безопасности у компании Y нет, то вас пригласили провести комплексный анализ процесса разработки и протестировать на наличие других веб-уязвимостей (деталей по найденным и исправленным уязвимостям не предоставили, поскольку “вы же профессионалы, должны проверить всё с чистого листа”).Конечно же, разработчики со стороны подрядчика также максимально пошли вам на встречу и предоставили исчерпывающую информацию о приложении, целых две ссылки на репозитории с кодом:

https://github.com/Netology-cp/sib/tree/main/Front

https://github.com/Netology-cp/sib/tree/main/BackПо словам разработчиков:

• Вся разработка ведётся в приватных репозиториях в GitHub (это легенда, для удобства мы вам предоставили открытые репозитории).
• Весь код (а также зависимости и контейнеры) регулярно проходит проверку открытыми инструментами*:
• https://github.com/
• https://detekt.dev/
• Сам код покрыт авто-тестами, включая проверку механизмов безопасности (отработка неверных логинов/паролей), которые регулярно прогоняются (при каждом push в репозиторий).
• Разработчики прекрасно знакомы с OWASP Top 10, а некоторые даже и с ASVS, и WSTG.
• Кроме того, они придерживаются строгих правил разработки и не разрешают push'ить в master без соответствующего Code Review (как минимум, двух человек) и прохождения автоматизированных проверок.
• После прохождения всех проверок автоматически собираются образы Docker и публикуются в GitHub Container Registry (для дальнейшего разворачивания в Production).

Важно: отчёты этих инструментов скрыты из публичного доступа. При желании вы можете Fork'нуть репозиторий и самостоятельно настроить репозиторий.Инструкция по запускуИспользуйте следующий файл Docker Compose:ЗадачаВаша ключевая задача - провести комплексное исследование как функционирующего приложения, так и исходных кодов (обратите внимание на код самого приложения, всё ли в порядке с зависимостями, “правильно” ли собираются контейнеры и т.д.)..

Важно: в задачу не закладывается требование “выучить” используемые в системе языки программирования, достаточно знания английского языка и умения гуглить некоторые важные моменты (например, как в том или ином языке работать с генерацией случайного набора данных или что такое CORS, CSRF и т.д.)..

Рекомендуем разложить задачу на 3 этапа:

• Планирование.
• Непосредственно выполнение работы.
• Подготовка отчётных документов по итогам.

ПланированиеВ первую очередь, вы должны составить план работ, в котором описано:

• что вы будете проверять;
• как вы будете это проверять (инструменты, подходы, используемые нормативные документы, стандарты или руководства);
• интервальная оценка с учётом рисков (в часах);
• план сдачи работ (когда будут выполнены работы и будет готов отчёт).

Выполнение работНа этом этапе вы непосредственно выполняете работу.Отчётные документы по итогам тестированияВ качестве отчётных документов прикладываются:

• Документ (doc, odf, pdf или issue в GitHub) со скриншотами и описанием обнаруженных проблем (если они есть).
• Документ с рекомендациями (улучшения процесса, кода, подходов, применения новых практик и т.д.).

О документахВажно: когда мы просим вас написать любые документы - мы не требуем творений на 10 страниц текста. Пишите только то, что действительно важно. Но и документы в формате 1-2 строчек тоже приниматься не будут.Критерии сдачи

• Найдено минимум 5 проблем
• Подготовлен отчёт
• Подготовлены рекомендации по решению проблем