Прийом файлів від користувачів завжди пов'язаний з ризиками. Про це йдеться в Security Tip #53 від Стівена Ріс-Картера зі Securing Laravel. Автор нагадує: завантажені файли можуть дуже легко допомогти обійти захист від CSRF і захист cookie.
Чому завантаження файлів небезпечні
Нa відміну від іншого користувацького вводу, вміст файлу зазвичай не можна повністю перевірити або жорстко обмежити, а потім безпечно зберегти в базі даних. Файли потрібно класти в папку на диску, і залежно від завдання вони часто мають бути доступні всьому світу.
Саме це і є головною проблемою: світова доступність.
Перше, про що думають розробники, - це завантаження .php-файлів і спроба отримати RCE. Це справді найбільший ризик, але не слід забувати і про .html, і навіть про .js-файли, а також про те, звідки вони доступні.
Обмежуйте типи файлів
Загальне правило - завжди обмежувати типи файлів, які дозволено завантажувати. Для цього автор радить валідацію завантажених файлів у Laravel: вона дуже надійна, тому варто перевіряти нею все.
Але що робити, якщо потрібно приймати широкий набір файлів або навіть саме .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-скрипт.
Усе зводиться до управління ризиками.
