Кэширование классами

Шаблонизатор TWIG хранит кэш, создавая классы и записывая их в файлы. При загрузке шаблона, проверяет есть ли файл с классом, не устарел ли и т.п. Потом использует класс через автозагрузку.

Вот у меня назрел общий вопрос. А насколько это безопасно? Например, если в файл с классом затолкать код (вне класса), то при загрузке класса этот код выполнится. И если в случае с постоянно используемыми классами, насколько понимаю, можно на файлы с классами поставить запрет на запись, то с кэшем так поступить не получится.

Соответственно, повторюсь, насколько такой вариант организации кэша безопасен и стоит ли в этом направлении беспокоиться дальше?

А не разрешайте пользователям заталкивать код в php файлы.

Если кто-то посторонний имеет доступ к ФС - беспокоиться уже поздно. Гасить сервер и полный аудит, что откуда и как влезли.

-----
PostgreSQL DBA

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

ну насколько я знаю тот же твиг работает по белому списку комманд. что это значит, сначала он парсит шаблон и саздает класс с тем же шаблоном, но только тем который уже распарсен и вместо {var} имеет echo $var (как то так). Тоесть если нехоршый человек имеет доступ к файловой системе, ему не составит труда изменить код в кеше, но шаблонизатор сам не пропустит код PHP в шаблоне. Поправьте если я не прав

esterio, а если измененный код добавит к той же $var еще и iframe ссылающийся на свою страницу для накрутки?
Тут уже скорее если смогли скомпрометировать файлы кэша, то нужно искать имеющиеся уязвимости.

я и говорю що если есть доступ к шаблонам но не страшно, но доступ к кешу равнозначно как доступ например к index.php

Так ведь xss можно делать.

Создает файл с классом. Имя класса - хэш имени шаблона (с солями и т.п.). При запуске не парсит, а ищет сначала нужный класс и проверяет время создания начального шаблона. Если время создания начального шаблона изменилось, то перепарсит, если кэша нет, то тоже.
Но суть не в этом. Можно же не в echo записать, а вообще вне класса.

Например, когда кэш хранится в /tmp директории на шаред хостинге.

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

(Отредактировано автором: 24 Февраля, 2014 - 15:42:23)

Ch_chov, проблема шаред хостингов и настроек. Разве нет?

(Отредактировано автором: 24 Февраля, 2014 - 15:33:45)

Вот эта фраза заставила меня переформулировать вопрос. Скорее, его нужно поставить так.

Хранить кэш в классах - это элегантно и быстро. Но хранить кэш в сериализованном каким-либо образом виде, вероятно, безопаснее. При этом при десериализации можно избежать запуска измененного кода, но, безусловно, потерять в производительности. Дак вот, если принять за условие, что TWIG или другой подобным образом работающий шаблонизатор сам не пропускает в кэш чужой код, но он попадает в кэш через другие дырки, то при сериализованных шаблонах появляется дополнительная защита, но падает, как я уже сказал скорость обработки. И вопрос в том стоит ли париться в этом случае или такая вставка кода, если она случилась, безусловно не будет отнесена на счет шаблонизатора.

Условно, не получим в итоге фразы, что это шаблонизатор виноват, потому что вот если бы он хранил кэш в сериализованном виде, то такого бы не произошло?

Нет, проблема именно в разработчиках, которые используют дефолтную tmp директорию, для хранения "небезопасных" файлов. В unix системах /tmp должна быть доступна для записи и чтения. От этого может зависеть роботоспособность некоторых программ.
(Добавление)
Если кто то получил доступ к файловой системе сервера, то метаться уже поздно. Какой смысл вставлять код в компилированные шаблоны, которые будут перезаписаные после сброса кэша? Ведь на сервере наверняка, есть куча других php файлов.

Логично. Но суть в следующем. По идее на все можно поставить запрет на запись, а на кэш нельзя (ну по определению). Скажем, получил ты доступ к исполнению php кода через иньекцию, но все вокруг только для чтения. В таком случае изменить можно только кэш. Я так рассуждаю. Поправьте, если не прав.

Попутный вопрос. Средствами php, насколько я понимаю, атрибуты файлов менять можно. А при любых настройках? Просто если можно, то тогда в итоге, действительно, по большому счету все равно какие атрибуты стоят на файлах. И, действительно, проще искать варианты размещения shell в постоянных скриптах, а не в кэше.

(Отредактировано автором: 24 Февраля, 2014 - 16:05:32)