Skip to content

AdvancedJavaLabs/lab4-security-Leatherlord

 
 

Repository files navigation

Review Assignment Due Date

Лабораторная работа №4 — Анализ и тестирование безопасности веб-приложения

Цель

Научиться находить уязвимости в реальном коде, формулировать security test cases, классифицировать проблемы через CWE, оценивать их серьёзность через CVSS и оформлять результаты как профессиональный pentest-отчёт.


Описание приложения

Учебное REST API на Javalin (Java) для аналитики пользовательской активности.

Эндпоинты

Метод Путь Параметры Описание
POST /register userId, userName Регистрация пользователя
POST /recordSession userId, loginTime, logoutTime (ISO 8601) Запись сессии активности
GET /totalActivity userId Суммарное время активности (в минутах)
GET /inactiveUsers days Список неактивных пользователей
GET /monthlyActivity userId, month (yyyy-MM) Активность по дням за месяц
GET /userProfile userId HTML-профиль пользователя
GET /exportReport userId, filename Экспорт отчёта в файл на сервере
POST /notify userId, callbackUrl Уведомление по webhook

Запуск приложения

./gradlew run
# Сервер стартует на http://localhost:7000

Задание

Этап 1 — Asset Inventory (инвентаризация активов)

Перед поиском уязвимостей необходимо понять, что именно защищаем.

Заполните таблицу активов системы:

Актив Тип Ценность Примечание
Данные пользователей (userId, userName) Данные ?
Данные о сессиях (время входа/выхода) Данные ?
Файловая система сервера Инфраструктура ?
Внутренняя сеть / метаданные окружения Инфраструктура ?

Вопрос для размышления: какие из активов наиболее критичны и почему?


Этап 2 — Threat Modeling

Проведите базовое моделирование угроз по методологии STRIDE:

Категория угрозы Расшифровка Применимо к этому приложению?
Spoofing Подмена идентификации ?
Tampering Модификация данных ?
Repudiation Отказ от авторства ?
Information Disclosure Утечка данных ?
Denial of Service Отказ в обслуживании ?
Elevation of Privilege Повышение привилегий ?

Для каждой применимой угрозы укажите:

  • Источник угрозы (кто/что может её реализовать)
  • Поверхность атаки (через какой эндпоинт/параметр)
  • Потенциальный ущерб

Этап 3 — Ручное тестирование

Исследуйте каждый эндпоинт вручную — с помощью curl, Postman, Burp Suite или браузера.

Что проверять:

  • Как приложение обрабатывает неожиданные значения параметров?
  • Что происходит при передаче спецсимволов (<, >, ", ', /, ..)?
  • Что возвращается в теле ответа при ошибках?
  • Что происходит с параметрами-путями к файлам или URL?
  • Есть ли ограничения на количество запросов или размер данных?

Пример — начало исследования /userProfile:

# 1. Зарегистрировать тестового пользователя
curl -X POST "http://localhost:7000/register?userId=test&userName=Alice"

# 2. Посмотреть, как отображается профиль
curl "http://localhost:7000/userProfile?userId=test"

# 3. Попробовать имя со спецсимволами
curl -X POST "http://localhost:7000/register?userId=evil&userName=%3Cscript%3Ealert(1)%3C%2Fscript%3E"
curl "http://localhost:7000/userProfile?userId=evil"
# → Что вернёт сервер? Что отрендерит браузер?

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


Этап 4 — Статический анализ с Semgrep

Semgrep — инструмент статического анализа кода, который ищет паттерны уязвимостей без запуска приложения.

Установка

# Linux / macOS (через pip)
pip install semgrep

# macOS (через Homebrew)
brew install semgrep

# Проверка установки
semgrep --version

Запуск на проекте

# Перейти в корень проекта
cd /path/to/software_testing_lab_4

# Базовый запуск — встроенные правила для Java
semgrep --config "p/java" src/

# Расширенный запуск — правила безопасности OWASP
semgrep --config "p/owasp-top-ten" src/

# Сохранить отчёт в формате SARIF
semgrep --config "p/java" --sarif -o semgrep-report.sarif src/

Что такое SARIF?

SARIF (Static Analysis Results Interchange Format) — стандартный формат обмена результатами статического анализа (ISO/IEC 5055). Используется в GitHub Actions, GitLab CI, VS Code и IDE для отображения findings прямо в интерфейсе.

Откройте semgrep-report.sarif и изучите структуру:

{
  "$schema": "https://json.schemastore.org/sarif-2.1.0.json",
  "version": "2.1.0",
  "runs": [{
    "tool": { "driver": { "name": "Semgrep", "rules": [ ... ] } },
    "results": [{
      "ruleId": "java.lang.security.audit.xss.no-direct-response-writer",
      "level": "warning",
      "message": { "text": "..." },
      "locations": [{
        "physicalLocation": {
          "artifactLocation": { "uri": "src/..." },
          "region": { "startLine": 42 }
        }
      }]
    }]
  }]
}

Ключевые поля для отчёта:

Поле SARIF Что означает
ruleId Идентификатор правила / уязвимости
level Серьёзность: error, warning, note
message.text Описание проблемы
locations[].region.startLine Строка в исходном коде
relatedLocations Связанные места (data flow)

Что делать с результатами

  1. Изучите каждый finding в выводе и в .sarif-файле
  2. Определите, является ли он реальной уязвимостью или ложным срабатыванием (false positive)
  3. Для каждого finding сопоставьте ruleId с соответствующим CWE
  4. Включите результаты Semgrep в финальный отчёт с пометкой о верификации

Важно: Semgrep — вспомогательный инструмент. Статический анализ не заменяет ручное тестирование. Некоторые уязвимости он найдёт, некоторые — нет.


Этап 5 — Оформление отчёта

Для каждой найденной уязвимости заполните карточку по следующему шаблону:


🔴 Finding #N — [Название уязвимости]

Поле Значение
Компонент Эндпоинт или класс, где обнаружена уязвимость
Тип Краткое название (например: Reflected XSS)
CWE CWE-XXX — название
CVSS v3.1 Числовой балл (0.0–10.0) и вектор, например: 7.5 HIGH (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)
Статус Confirmed / Suspected / False Positive

Описание:

Что происходит и почему это проблема.

Шаги воспроизведения:

1. ...
2. ...
3. Ожидаемый результат: ...
   Фактический результат: ...

Влияние:

Что может сделать атакующий, если воспользуется уязвимостью.

Рекомендации по исправлению:

Конкретные меры: какой метод/библиотеку использовать, какую проверку добавить.

Security Test Case:

@Test
@DisplayName("[SECURITY] ...")
void testName() {
    // Arrange
    // Act
    // Assert — проверить, что уязвимость закрыта
}

Пример оформленного finding

В качестве образца изучите файл:

src/test/java/ru/itmo/testing/lab4/pentest/XssPentestTest.java

Он демонстрирует структуру pentest-теста для одной из уязвимостей приложения.
Ваша задача — найти остальные, описать их по шаблону выше и написать аналогичные тесты.


Полезные ресурсы

About

software_testing_spring_2026-lab4-security-lab4-security created by GitHub Classroom

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages

  • Java 87.1%
  • Shell 12.9%