безопасности ESI проблема с Symfony2

Question

Я столкнулся с проблемой безопасности с ESI на Symfony2 (2.2):

Некоторые ESI моего приложения не требуют, чтобы быть зарегистрированным и общедоступны, но и другие ESI требуется, чтобы пользователь регистрировался и, например, выполнял роль ROLE_USER.

Проблема заключается в том, что каждый парень может отображать ESI, написав свой URL-адрес в адресной строке навигатора ... Таким образом, человек может получить доступ к ESI (который вызывается внутри действия, требующего роли администратора) , даже никто не регистрировался!

Например, мой ESI «SybioWebsiteBundle: Контроллер: showEsiAction» можно прочитать по этой ссылке: http://mywebsiteurl.com/_proxy?_path=id%3D1%26slug%3Dlorem%26locale%3Dfr%26ranks%3D1-2-3-5-6-7%26page%3D1%26isPhotograph%3D1%26_format%3Dhtml%26_controller%3DSybioWebsiteBundle%253AAlbum%253AshowEsi

Этого ESI должен быть виден только зарегистрированными пользователями: они идут в showAction, а внутри шаблона Twig, этот ESI называется ... Но все люди могут обманывать и читать благодаря этой «проблеме»!

Я искал решение, я получил один очень уродливые: проверки, если пользователь вошел в действии ESI ... это нормально, но я использую HTTP проверку кэша оптимизировать мой сайт загрузку (и память) , Поэтому, если я выберу это решение, мне нужно добавить дополнительный ETag, который проверяет роль пользователя, очищать кеш ESI каждый раз, когда пользователь не имеет доступа к ESI, и отображает пустой ответ, а после того, как он регистрируется, очистите его снова и отобразить нормальный вид и т. д.

Теперь я хочу, чтобы люди, которые хотят обмануть, будут необычными, поэтому это может быть насыщающее решение ... Теоретически кеш не будет постоянно очищаться из-за их, к счастью!

Но я хочу знать, есть ли у вас другое решение? Благодаря !

Answer 1

В версиях <=2.1 URL-адрес ESI поступает из импорта файла маршрутизации internal.xml, в котором показан обычный маршрут Symfony, который способен визуализировать любой контроллер.

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

В файле >=2.2 файл маршрутизации internal.xml отсутствует. Теперь у вас есть ключ фрагмента в config.yml. Вместо маршрута это активирует прослушиватель, который следит за любыми запросами, начинающимися с /_proxy, который является URL-адресом, который теперь отображают теги ESI.

Это само по себе не помогает безопасности, за исключением того, что слушатель использует несколько трюков внутри.

Итак, что мешает злому пользователю использовать этот URL для отображения любого контроллера в нашей системе с любыми параметрами? Начиная с 2.2, существуют две встроенные защиты: доверенные прокси и подписанные URL-адреса.

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

Если вы используете обратный прокси-сервер, такой как Varnish, тогда вы захотите добавить свой IP-адрес или - диапазон IP-адресов CIDR для супергиков - в свою конфигурацию.yml file:

framework 
    trusted_proxies: 
     - 192.168.12.0 

Если запрос исходит от этого IP-адреса или диапазона, он позволяет это. И, если это происходит из локального адреса, это также позволяет. Другими словами, если это кому-то, кому вы доверяете, тогда все в порядке.