---
title: "Порада з безпеки: як завантаження файлів може обійти захист від CSRF"
url: https://laravelukraine.com/blog/porada-z-bezpeki-iak-zavantazennia-failiv-moze-obiiti-zaxist-vid-csrf
date: 2026-10-09
source: https://securinglaravel.com/security-tip-bypassing-csrf-protection/
---

# Порада з безпеки: як завантаження файлів може обійти захист від CSRF

Прийом файлів від користувачів завжди пов'язаний з ризиками. Про це йдеться в [Security Tip #53](https://securinglaravel.com/security-tip-bypassing-csrf-protection/) від Стівена Ріс-Картера зі Securing Laravel. Автор нагадує: завантажені файли можуть дуже легко допомогти обійти захист від CSRF і захист cookie.

## Чому завантаження файлів небезпечні

Нa відміну від іншого користувацького вводу, вміст файлу зазвичай не можна повністю перевірити або жорстко обмежити, а потім безпечно зберегти в базі даних. Файли потрібно класти в папку на диску, і залежно від завдання вони часто мають бути доступні всьому світу.

**Саме це і є головною проблемою: світова доступність.**

Перше, про що думають розробники, - це завантаження `.php`-файлів і спроба отримати RCE. Це справді найбільший ризик, але не слід забувати і про `.html`, і навіть про `.js`-файли, а також про те, звідки вони доступні.

## Обмежуйте типи файлів

Загальне правило - завжди обмежувати типи файлів, які дозволено завантажувати. Для цього автор радить [валідацію завантажених файлів у Laravel](https://laravel.com/docs/validation?ref=securinglaravel.com#validating-files): вона дуже надійна, тому варто перевіряти нею все.

Але що робити, якщо потрібно приймати широкий набір файлів або навіть саме `.html`?

## У чому ризик HTML-файлів

Якщо зловмисник може завантажити HTML-файл, який браузер виконає як HTML, він зможе запустити JavaScript у браузері жертви. Залежно від області (scope), у якій виконується цей файл, він може отримати повний доступ до сесійних cookie та CSRF-токенів. Тоді CSRF- та XSS-атаки стають тривіальними, а застосунок - повністю беззахисним.

## Порівняння варіантів розміщення файлів

Автор розглядає сценарій, коли основний застосунок працює на `securinglaravel.com`, а завантажені файли доступні для перегляду чи завантаження.

### `securinglaravel.com/downloads/upload.html`

- ❌ Файл напряму в межах основного домену.
- ❌ Повний доступ до автентифікаційних cookie.
- ❌ Повний доступ до CSRF-токенів.
- ❌ `.php`-файли можуть виконуватися, що дає RCE у застосунку.

### `cdn.securinglaravel.com/upload.html`

- ❌ Пов'язаний з областю основного домену.
- ❌ Перебуває в області «Same-Site» з основним доменом, тож обходить захист, який дають `SameSite=Lax` і `SameSite=Strict`.
- ⚠️ CSRF-токени потенційно доступні, якщо піддомени входять в область дії cookie.
- ⚠️ `.php`-файли можуть виконуватися, що дає повний доступ до всіх завантажених файлів і потенційно до всього застосунку.

### `securinglaravel.some-cdn-provider.com/upload.html`

- ✅ Незалежний домен поза областю основного.
- ✅ Cookie заблоковані.
- ✅ CSRF-токени отримати неможливо.
- ✅ Будь-який пристойний CDN чи файлове сховище не дозволить виконувати серверні файли (наприклад, `.php`).

## Висновок

Навіть якщо ви спеціально не дозволяєте завантажувати `.html`, автор наполегливо радить віддавати завантажені файли з повністю окремого домену. Це запобігає обходу CSRF і cookie-захисту, а якщо сервіс узагалі не підтримує виконання PHP-скриптів, то ви не ризикуєте, навіть коли хтось зуміє туди завантажити PHP-скрипт.

Усе зводиться до управління ризиками.