Skip to content
KitploitKITPLOIT
ИнструментыЭксплойтыБлог
Log in
Отправить
ИнструментыЭксплойтыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

ЛентыКонтактыКонфиденциальность© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
vuln-chain-lab — PoC Docker лаборатория: связывание обхода загрузки файлов + хранимая XSS для создания учетных записей администратора. Образовательный ресурс для пентестеров. | Kitploit
Инструменты/GitHubGitHub/echosecure/vuln-chain-lab
Анализ уязвимостейЭксплуатация веб-приложенийВеб-безопасностьCTFТестирование на ПроникновениеНеправильная КонфигурацияОбучение и ОбразованиеЛаборатории и Практика
GitHubechosecure/vuln-chain-lab

vuln-chain-lab

PoC Docker лаборатория: связывание обхода загрузки файлов + хранимая XSS для создания учетных записей администратора. Образовательный ресурс для пентестеров.

1206 месяцев назадЕщё не проверено
Репозиторий

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться

File Upload Bypass + Stored XSS PoC Lab

Намеренно уязвимое веб-приложение, демонстрирующее, как обход загрузки файлов сочетается с хранимой XSS для создания бэкдор-учетных записей администратора, даже при наличии CSP, CORS и CSRF-защиты.

Полная статья в блоге: KurtiseBear Blog

Это образовательный лабораторный стенд для обучения защите. Не разворачивайте его в общедоступном месте.

Что демонстрируется

Приложение имеет реальные средства защиты:

  • Политика безопасности контента (CSP), ограничивающая источники скриптов значением 'self' (но с разрешёнными 'unsafe-inline' и 'unsafe-eval')
  • Заголовки CORS не отправляются, поэтому кросс-доменные запросы блокируются браузерами
  • CSRF-токены во всех отправляемых формах (сообщения, загрузка файлов)
  • Стандартные заголовки безопасности (X-Content-Type-Options, X-Frame-Options, Referrer-Policy)

Злоумышленник с учётной записью низкопривилегированного пользователя объединяет две уязвимости, чтобы обойти все эти защиты:

  1. Обход загрузки файлов — Форма загрузки ограничивает выбор .pdf с помощью клиентского атрибута accept, но сервер не выполняет никакой проверки типа файла. Злоумышленник загружает .js-файл, содержащий JavaScript. Конечная точка загрузки отдаёт его с того же источника, поэтому CSP и CORS не блокируют его.

  2. Хранимая XSS через тему сообщения — Функция отправки сообщений сохраняет пользовательский ввод без санитизации. Папка входящих администратора отображает тему сообщения как сырой HTML. XSS-пейлоад использует обработчик `` для загрузки загруженного скрипта и выполнения его через eval(). CSP разрешает это, так как 'unsafe-inline' и 'unsafe-eval' разрешены.

  3. Отсутствие CSRF на конечной точке API — API управления пользователями (/api/manage-user.php) не проверяет CSRF-токены, хотя конечные точки форм это делают. XSS-пейлоад вызывает этот API, используя сессию администратора с тем же источником. Даже если бы CSRF присутствовал, JavaScript с того же источника мог бы прочитать токен из DOM.

Результат: когда администратор открывает свою папку входящих, XSS срабатывает, JavaScript создаёт бэкдор-учётную запись администратора, используя сессию администратора. Все средства защиты включены и работают. Цепочка работает, потому что никогда не покидает источник.

Предварительные требования

  • Docker
  • Docker Compose

Настройка

docker-compose up -d

Подождите 10-15 секунд, пока инициализируется MySQL, затем перейдите на http://localhost:8080

Учётные данные

РольEmailПароль
Админ[email protected]admin
Пользователь[email protected]user

Пошаговое выполнение атаки

Шаг 1: Войдите как обычный пользователь

Перейдите на http://localhost:8080 и войдите с [email protected] / user.

Шаг 2: Загрузите пейлоад

Перейдите в Upload Files. Форма говорит «Только PDF», но это ограничение реализовано только на стороне клиента. Либо:

  • Используйте инструменты разработчика браузера, чтобы удалить атрибут accept=".pdf" из поля выбора файла, или
  • Используйте curl/Burp для прямой загрузки (вам понадобится CSRF-токен из формы)

Загрузите предоставленный payload.js (или свой собственный). Запомните возвращённый ID файла (например, 1).

Теперь загруженный файл доступен по адресу /api/download.php?file_id=1 на том же источнике. CSP не будет блокировать запросы к этой конечной точке, потому что она находится в 'self'.

Шаг 3: Создайте XSS-сообщение

Перейдите в Send Message. В поле темы введите:

r.blob()).then(b=>b.text()).then(eval)">

(Замените 1 на фактический ID файла из шага 2.)

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

Обработчик onerror срабатывает, потому что CSP разрешает 'unsafe-inline'. Функция eval() работает, потому что CSP разрешает 'unsafe-eval'. Fetch к конечной точке загрузки работает, потому что она с того же источника.

Шаг 4: Дождитесь, пока администратор проверит свою папку входящих

Выйдите из системы. Войдите как [email protected] / admin. Перейдите в Inbox.

Тема сообщения отображается как сырой HTML. Тег `` не загружается, срабатывает обработчик onerror, загружает загруженный пейлоад и выполняет его через eval(). Пейлоад отправляет POST-запрос на /api/manage-user.php, используя куки сессии администратора (автоматически прикрепляются для запросов с того же источника). CSRF-токен не требуется, потому что конечная точка API его не проверяет.

Шаг 5: Проверьте бэкдор

Перейдите в Users. Вы должны увидеть нового пользователя: BackdoorAdmin с ролью admin и email [email protected].

Выйдите и войдите с [email protected] / Compromised1!, чтобы подтвердить.

Почему защиты не сработали

CSP блокирует внешние скрипты
  --> Но пейлоад размещён на том же источнике через загрузку файла
  --> И unsafe-inline/unsafe-eval позволяют обработчику onerror и eval()

CORS блокирует кросс-доменные запросы
  --> Но все запросы в цепочке выполняются с того же источника

CSRF-токены защищают отправку форм
  --> Но конечная точка API их не проверяет
  --> И даже если бы проверяла, JS с того же источника может читать токены из DOM

Куки сессии имеют стандартные защиты
  --> Но запросы с того же источника передают их автоматически

Все защиты работают корректно. Они предназначены для остановки кросс-доменных атак. Эта цепочка никогда не покидает источник.

Меры защиты

Что действительно разорвало бы эту цепочку:

  1. Проверка типа файла на стороне сервера — Проверяйте MIME-тип, расширение файла и магические байты. Не доверяйте клиенту. Это предотвращает размещение пейлоада злоумышленником на вашем источнике.
  2. Кодирование вывода — Используйте htmlspecialchars() для всех данных, контролируемых пользователем. Папка входящих отображает $row['subject'] как сырой код. Это полностью устраняет XSS.
  3. Строгий CSP — Удалите 'unsafe-inline' и 'unsafe-eval'. Используйте nonce или хеши для легитимных встроенных скриптов. Это блокирует обработчик onerror и eval().
  4. Content-Disposition: attachment — Принудительно загружайте файлы вместо их встроенного отображения для загруженных пользователями файлов. Это предотвращает интерпретацию браузером загруженного содержимого.
  5. CSRF на всех конечных точках, изменяющих состояние — Включая конечные точки API, а не только формы.
  6. Контроль доступа к загруженным файлам — API загрузки отдаёт любой файл любому аутентифицированному пользователю. Файлы должны быть привязаны к их владельцу.

Очистка

docker-compose down -v

Отказ от ответственности

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

Скачать инструмент