Laravel по-русски

Tarasovych +2

Сообщений: 43

Защита он инъекций через загрузку файлов

Как защитить сайт от инъекции вида:
http://site.com/main/index.php?page=[здесь уязвимость]
Допустим загружается файл через "прикрепить файл" или другую форму обратной связи, который потом вышеописанным образом инклудится и исполянется.

constb +141

Мастер

Сообщений: 624

Re: Защита он инъекций через загрузку файлов

а) валидировать то что загружается – https://laravel.com/docs/5.4/validation, б) не класть загруженное в паблик, отдавать его через маршруты и скрипты

(б) кажется должно довольно сильно нагружать сервер, но я вот скажу, у меня на одном проекте у картинок ресайзы все сделаны на лету с помощью league/glide (http://glide.thephpleague.com/1.0/confi … s/laravel/) и надо сказать – работает очень быстро, отчасти засчёт того что glide неплохо кэширует готовые картинки и активно задействует браузерный кэш

для отдачи не-картинок, если не будет большого количества запросов на скачивание – (б) и только (б). в ларавеле уже есть удобный хэлпер для отдачи файлов в респонсе – response()->download()

Proger_XP +345

Топ 30%

Мастер

Сообщений: 1,312

Статей: 33

Re: Защита он инъекций через загрузку файлов

Зачем для этого использовать PHP? С пережатием отлично справляется nginx, у него куча настроек и он очень быстрый (быстрее PHP). И, весьма возможно, безопаснее. См. ngx_http_image_filter_module.

Аналогично, с этим лучше справится веб-сервер. Для nginx есть модуль для генерации уникальных ссылок (т.е. PHP авторизует клиента и делает редирект на статический файл). См. ngx_http_secure_link_module.

---

Но вообще описанные средства на поставленный вопрос не отвечают.

• Валидировать загруженное — сложная тема; спасёт ли от PHP include поиск <? в загруженных данных? А какой будет процент ложных срабатываний?
• Загруженное вполне можно и часто нужно выкладывать в public, безопасность этого зависит от настроек сервера.
• Отдавать всё, в т.ч. гигантские файлы через скрипты это заставлять PHP делать работу веб-сервера.
• Далеко не все проблемы вызваны доступностью загруженных ресурсов напрямую из Сети. Как пример — проблема с ImageMagick (поэтому используя какие-то библиотеки на PHP вы вполне можете заполучить и эту дыру).

Чтобы избежать проблем нужно писать код, всегда держа его безопасность в уме. Другого варианта нет, решения «сверху» (типа WAF) можно обойти, плюс они могут резать вполне легитимные запросы. Это значит, что избежать PHP include можно отключением allow_url_fopen в php.ini и отсутствием любых include/require, которым передаётся переменная из пользовательского ввода.

В последнем случае надо понимать, что «пользовательский ввод» может оказаться совершенно в неожиданных местах. Например, у вас есть автозагрузчик, стандартный такого вида:

PHP

spl_autoload_register(function ($class) {
    include "classes/$class.php";
});

Здесь $class это обычная переменная без «грязного» ввода, так? Нет. PHP передаёт здесь любую строку, которая даже не похожа на имя класса. К примеру, если у пользователя есть возможность менять сериализованные строки (PHPserialize()), то он может «создать» класс с именем типа ../public/upload/avatars/myavat00r.png\0 и в старых версиях PHP у вас будет PHP include (в новых не будет, т.к. NUL-byte обрабатывается корректно и расширение .php останется в строке). Однако новые версии PHP могут не спасти от проблем где-то в другом месте в коде.

Поэтому как вариант — перед каждым include/require с переменной проверять значение этой переменной, например, содержит ли она какие-то символы, кроме допустимых в идентификаторах.

Абсолютного решения для всех этих проблем нет. Уровень паранойи может быть очень разным и многие просто закрывают на безопасность глаза, потому что «ну кому нужен мой сайт».