Аудит joke-php/templator на коммите eecfa4b7dec3897f24dafa30cd450abada15fa0b

Короткое резюме

Коммит eecfa4b7dec3897f24dafa30cd450abada15fa0b реализует шаблонизатор с компиляцией AST в PHP и последующим include кэшированного файла. Ключевой риск не в классическом eval , а в цепочке compileFile() → сырой TextNode → include $cache->path : при неограниченном пути к шаблону это даёт чтение произвольных файлов, а при попадании в шаблон текста с <?php ... ?> — исполнение PHP-кода из “текстового” шаблона.

Топ-5 критичных/высоких проблем в этом коммите:

1. LFI/path traversal через includeFile() / compileFile() : путь к шаблону никак не ограничен корнем шаблонов и читается напрямую через file_get_contents() .
2. RCE через “обычный текст” шаблона: TextNodeHandler возвращает сырой текст без экранирования/нейтрализации PHP-тегов, а кэш затем исполняется через include .
3. Расхождение compile vs render на отсутствующих ключах: compiled-mode генерирует прямой доступ вида $context['user']['name'] , тогда как render-mode идёт через resolveValue(..., $default) ; это ломает предсказуемость и приводит к предупреждениям PHP на пустых данных.
4. Потеря внешних локальных переменных в вложенных foreach при компиляции: внутренний цикл затирает список localVars , из-за чего обращения к переменным внешнего цикла компилируются уже как $context[...] .
5. {% csrf %} создаёт ложное ощущение защиты: код выводит только сырой токен, а не hidden-input; кроме того, compiled/render paths ведут себя по-разному при недоступных сервисах.

php

// Плохо: путь приходит извне
$engine->includeFile($_GET['tpl'], []);

// /page?tpl=../../../../etc/passwd

php

file_put_contents('/tmp/tpl.php', '<?php echo "PWNED"; ?>');
$engine->includeFile('/tmp/tpl.php', []);
// Ожидание от шаблонизатора: вывести literal text
// Фактически: выполнить PHP-код

php

// Шаблон
{{ user.name }}

// Что генерирует компилятор по сути:
<?= htmlspecialchars((string)$context['user']['name'], ENT_QUOTES, 'UTF-8'); ?>

// Что делает render-mode:
$value = resolveValue($context, 'user.name', '', 'PrintNode'); // => ''

twig

{% foreach user in users %}
  {% foreach role in roles %}
    {{ user }}
  {% /foreach %}
{% /foreach %}

php

// Внутри inner-foreach localVars уже только ['role'],
// поэтому {{ user }} компилируется не в $user, а в $context['user'].

html

<form method="post">
  {% csrf %}
  <button>Save</button>
</form>

html

<form method="post">
  3c6f4b...
  <button>Save</button>
</form>

php

$template = str_repeat('a', 1_000_000) . '{{ user.name }}';

text

composer install
composer stan
composer fixer
composer test
# Psalm в этом коммите не настроен; для него сначала нужно добавить зависимость и конфиг.

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

ShowPage('index.xml');

Т.е. пользователь сказал что он хочет видеть страницу. Остальное не его проблемы.  Даже могу продемонстрировать на твоем фреймворке. (на той версии что у меня и, оговорюсь, я уже подзабыл его детали реализации, так что только по беглому поиску и взгляду) Правда тут с некоторым допущением у тебя сразу логика запускается некоторая на основе разбора xml. Но ее можно упаковать (в этом случае правда больше подойдет "классический кеш" (наподобии как описан в PSR)

class Manual {
   final public function Load(string $name){
//..некоторый код
      if(file_exists($way)){
        $cache = new FileRelatedCache('/tmp',$way, 86400);
        if ($cache->exsists()) {
          // достаем из кеша 
        } else {
          $xml=simplexml_load_file($way);
          if($xml){
            // обработка 
            $cache->save($data);
          }
        }
      }
//..некоторый код
   }
}

Т.е. все происходит внутри твоего метода. Это можно и не показывать пользователю, только дать ему инструмент сброса кеша по требованию

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

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

Пасиб. подумаю.

Тут идея такая то все же localVars это переменные блока. тоже еще у меня нет 100% видения как правильно. Вероятно уже по обкатаю на том же проекте форума - может что пойму для себя. :)

Интересно. подумаю

Тут из собственного опыта. На самом деле надо и так и так. Скорее всего будет добавлена директива типа csrf-input.

Да. TODO там не спроста :)  обязательно этот вопрос будет изучаться.

Об этом, если честно, даже не подумал...

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

ЗЫ. Эксперимент с обезьянками помнишь, я лично его почти всегда в такие моменты вспоминаю.

Это, кстати, я могу аргументировать:

1. Любой человек в любой области накапливает опыт. В этом накопленном опыте ему что то нравится, что то нет и так далее. Переходя к разработке фреймоворков: вполне естественно, что имея за плечами опыт разработки в не учебных/академических проектах накапливаешь опыт: какие решения, идеи хорошие и удобные, какие нет. Соотвтственно и свое решение строишь с учетом опыта. Берешь на вооружение хорошее и удобное (и этом может быть алгоритмы, идеи, интерфейсы взаимодействия, те же стандарты, PSR и прочее и прочее) - делаешь свою реализацию, а что показалось плохим и не удобным переделываешь. Если опыта нет (особенно даже если учебного) - то тут будет все по максимуму свое. Но у меня нет цели делать из принципа "главное, чтоб не было похоже на что то существующее" (считаю такой принцип не разумным). по этому да у меня есть решения которые похожи на типовые.

2. Фреймоворк должен быть привычным. Особенно в той парадигме в которой задумал я: он должен подходить для максимального числа проектов (в т.ч. и для чайников - через создание на его базе конструктора сайтов или MCP сервера, помогающего чайнику объяснить словами свои хотелки ИИ, а тот ему сгенерит).    А если расчет и на разработчиков глупо их полностью переучивать. Фреймворк должен помогать выполнять основную задачу, а не загружать мозг дополнительными навыками.  При чем если делать исходя "главное чтоб не как у всех" придется и самому полностью переучиваться, а это не имеет смысла в тех моментах которые считаешь правильными.