Часть I

В первом проекте участники создадут программное обеспечение с уязвимостями, укажут уязвимости в проекте и опишут шаги по их исправлению.

В проекте только 1 часть.

Перед началом курса

Прочитайте инструкции о том, как начать и пройти курс. Особенно внимательно изучите раздел о прохождении курса, поскольку для получения кредитов ECTS требуются дополнительные действия.

Канал поддержки и контактная информация

Для поддержки используйте Discord (канал #csb_general).

По дополнительным вопросам обращайтесь на grp-cybersecuritybase(at)removethis.helsinki.fi.

Описание проекта

В первом проекте курса вам нужно создать веб-приложение, в котором есть не менее 5 разных уязвимостей из списка OWASP Top Ten, а также их исправления. У приложения должна быть серверная часть.

OWASP недавно обновил свой список, и сейчас есть два списка: 2017 и 2021. Можно использовать любой из них, но укажите, какой именно. Не смешивайте списки. Обратите внимание, что CSRF отсутствует в обоих списках, поскольку сейчас встречается реже благодаря более защищенным фреймворкам. Однако из-за фундаментального характера CSRF разрешен как уязвимость.

Рекомендуем реализовать сайт с использованием Python и Django. Если вы проходили предыдущий курс, библиотеки Django у вас уже должны быть установлены. В противном случае см. инструкцию по установке. Чтобы создать начальный сайт, следуйте инструкциям здесь.

Вы можете выполнить проект без начального шаблона, на выбранном вами языке. В этом случае также нужно предоставить инструкции по установке и запуску веб-приложения на Windows, Linux и macOS, включая инструкции по установке всех возможных необходимых зависимостей.

Код должен храниться в публичном репозитории, чтобы другие студенты могли его проверить. Стандартный вариант — использовать GitHub. Если вы студент Университета Хельсинки, можно использовать https://version.helsinki.fi. Убедитесь, что проект является публичным. Самый простой способ проверить видимость — открыть ссылки в режиме инкогнито. Не удаляйте проект, пока не получите баллы.

Код также почти всегда должен содержать исправление уязвимости. Исправление должно быть закомментировано. Не используйте ветки git или отдельные версии для исправлений. Просто предоставьте уязвимости и закомментированные исправления в одной версии.

Кроме того, добавьте снимки экрана для каждой уязвимости, демонстрирующие ее эффект до и после исправления. Обычно это должны быть снимки экрана браузера, а в некоторых случаях — терминала сервера. Не включайте снимки экрана вашего кода. Убедитесь, что снимки экрана не содержат конфиденциальной информации. Можно добавить несколько снимков экрана, демонстрирующих эффект. Сохраните их в папке screenshots вашего репозитория и назовите flaw-1-before-1.png, flaw-1-after-1.png и так далее.

Убедитесь, что выполнены следующие условия, поскольку это самые частые причины отклонения проекта:

• Уязвимости реальные, а не только гипотетические, и исправления включены в код.
• Уязвимости находятся в коде или в скрипте установки; например, наличия пользователя admin/admin в базе данных недостаточно.
• Исправление действительно устраняет проблему, а не просто скрывает ее.
• Снимки экрана включены в репозиторий и названы в соответствии с инструкцией.
• Каждая уязвимость относится к отдельной категории.
• Уязвимости отнесены к правильным категориям. Особенно проблематична категория Insecure Design — её следует избегать.
• Есть серверная часть, и уязвимости/исправления находятся в серверной части. Помните, что пользователь может изменять клиентскую часть практически без ограничений.

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

Написание отчета

Затем вы напишете отчет объемом 1000 слов (жесткие ограничения: 800-1500), в котором точно укажете уязвимости и опишете, как их можно исправить. Отчет должен иметь следующую структуру:

LINK: link to the repository
installation instructions if needed

FLAW 1:
exact source link pinpointing flaw 1...
description of flaw 1...
how to fix it...

FLAW 2:
exact source link pinpointing flaw 2...
description of flaw 2...
how to fix it...

...

FLAW 5:
exact source link pinpointing flaw 5...
description of flaw 5...
how to fix it...

Добавьте ссылку на исходный код для каждой уязвимости, если это уместно. В идеале ссылка должна иметь формат https://urldomain/repo/file.py#L42 (строка 42 в file.py). Такие ссылки легко получить, нажав на номера строк в браузере файлов репозитория GitHub. Если уязвимость связана с отсутствием некоторого кода, закомментируйте этот код и предоставьте ссылку на начало закомментированного блока.

Описывайте исправление конкретно. Если возможно, предоставьте исправление проблемы в коде. Исправление должно быть закомментировано. Если уместно, добавьте ссылку на исходный код и для каждого исправления. Также можно ссылаться на снимки экрана.

Рекомендуем не писать отчет непосредственно в браузере. Вместо этого напишите и сохраните его в предпочитаемом текстовом редакторе, а затем скопируйте и вставьте в браузер.

Пишите отчет внимательно и вдумчиво. Другие участники курса будут рецензировать его и дадут вам обратную связь. Отчеты нужно писать индивидуально и своими словами. Копирование из других источников не разрешается. Копирование текста из других источников с выдачей его за свой считается плагиатом. Плагиат запрещен при любых обстоятельствах и будет иметь последствия при обнаружении. Информация об использовании LLM приведена здесь.

Взаимное рецензирование отчетов

Взаимное рецензирование состоит из общих комментариев и 5 оценок, по одной для каждой уязвимости.

Обоснуйте свои оценки в общих комментариях. Прокомментируйте каждую уязвимость. Будьте конкретны, конструктивны и вежливы.

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

Критерии оценивания следующие:

1. Не зачтено: уязвимость отсутствует или неприемлема по другой причине.
2. Достаточно: уязвимость определена правильно, исправление частично устраняет проблему. Базовая проблема и эффект исправления частично поняты неверно.
3. Средне: уязвимость описана достаточно, и исправление устраняет проблему. Есть небольшое недопонимание базового механизма. Описание слишком расплывчатое, но в целом правильное.
4. Хорошо: уязвимость и исправление выполнены правильно. В описаниях есть небольшие проблемы.
5. Отлично: проблем нет или есть только косметические замечания.

Отправка проекта