Покинул форум
Сообщений всего: 329
Дата рег-ции: Апр. 2011
Помог: 7 раз(а)
Шаблонизатор TWIG хранит кэш, создавая классы и записывая их в файлы. При загрузке шаблона, проверяет есть ли файл с классом, не устарел ли и т.п. Потом использует класс через автозагрузку.
Вот у меня назрел общий вопрос. А насколько это безопасно? Например, если в файл с классом затолкать код (вне класса), то при загрузке класса этот код выполнится. И если в случае с постоянно используемыми классами, насколько понимаю, можно на файлы с классами поставить запрет на запись, то с кэшем так поступить не получится.
Соответственно, повторюсь, насколько такой вариант организации кэша безопасен и стоит ли в этом направлении беспокоиться дальше?
Ch_chov
Отправлено: 24 Февраля, 2014 - 14:14:04
Постоянный участник
Покинул форум
Сообщений всего: 2121
Дата рег-ции: Июль 2008 Откуда: из города
Помог: 90 раз(а)
А не разрешайте пользователям заталкивать код в php файлы.
Мелкий
Отправлено: 24 Февраля, 2014 - 14:18:39
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
Если кто-то посторонний имеет доступ к ФС - беспокоиться уже поздно. Гасить сервер и полный аудит, что откуда и как влезли.
----- PostgreSQL DBA
MAXUS
Отправлено: 24 Февраля, 2014 - 14:30:21
Посетитель
Покинул форум
Сообщений всего: 329
Дата рег-ции: Апр. 2011
Помог: 7 раз(а)
Мелкий пишет:
Если кто-то посторонний имеет доступ к ФС - беспокоиться уже поздно. Гасить сервер и полный аудит, что откуда и как влезли.
Т.е. правильно я понимаю, что эту возможность надо отсекать на других уровнях кода, а за подобную реализацию кэша можно быть спокойным? Т.е. если кто-то в класс чего-то запихал, то косяк точно не в организации кэша подобным образом?
esterio
Отправлено: 24 Февраля, 2014 - 14:54:13
Активный участник
Покинул форум
Сообщений всего: 5025
Дата рег-ции: Нояб. 2012 Откуда: Украина, Львов
Помог: 127 раз(а)
ну насколько я знаю тот же твиг работает по белому списку комманд. что это значит, сначала он парсит шаблон и саздает класс с тем же шаблоном, но только тем который уже распарсен и вместо {var} имеет echo $var (как то так). Тоесть если нехоршый человек имеет доступ к файловой системе, ему не составит труда изменить код в кеше, но шаблонизатор сам не пропустит код PHP в шаблоне. Поправьте если я не прав
IllusionMH
Отправлено: 24 Февраля, 2014 - 14:59:17
Активный участник
Покинул форум
Сообщений всего: 4254
Дата рег-ции: Февр. 2011 Откуда: .kh.ua
Помог: 242 раз(а)
esterio, а если измененный код добавит к той же $var еще и iframe ссылающийся на свою страницу для накрутки?
Тут уже скорее если смогли скомпрометировать файлы кэша, то нужно искать имеющиеся уязвимости.
esterio
Отправлено: 24 Февраля, 2014 - 15:08:38
Активный участник
Покинул форум
Сообщений всего: 5025
Дата рег-ции: Нояб. 2012 Откуда: Украина, Львов
Помог: 127 раз(а)
я и говорю що если есть доступ к шаблонам но не страшно, но доступ к кешу равнозначно как доступ например к index.php
Ch_chov
Отправлено: 24 Февраля, 2014 - 15:13:57
Постоянный участник
Покинул форум
Сообщений всего: 2121
Дата рег-ции: Июль 2008 Откуда: из города
Помог: 90 раз(а)
esterio пишет:
если есть доступ к шаблонам но не страшно
Так ведь xss можно делать.
MAXUS
Отправлено: 24 Февраля, 2014 - 15:15:16
Посетитель
Покинул форум
Сообщений всего: 329
Дата рег-ции: Апр. 2011
Помог: 7 раз(а)
esterio пишет:
ну насколько я знаю тот же твиг работает по белому списку комманд. что это значит, сначала он парсит шаблон и саздает класс с тем же шаблоном, но только тем который уже распарсен и вместо {var} имеет echo $var (как то так). Тоесть если нехоршый человек имеет доступ к файловой системе, ему не составит труда изменить код в кеше, но шаблонизатор сам не пропустит код PHP в шаблоне. Поправьте если я не прав
Создает файл с классом. Имя класса - хэш имени шаблона (с солями и т.п.). При запуске не парсит, а ищет сначала нужный класс и проверяет время создания начального шаблона. Если время создания начального шаблона изменилось, то перепарсит, если кэша нет, то тоже.
Но суть не в этом. Можно же не в echo записать, а вообще вне класса.
Ch_chov
Отправлено: 24 Февраля, 2014 - 15:15:18
Постоянный участник
Покинул форум
Сообщений всего: 2121
Дата рег-ции: Июль 2008 Откуда: из города
Помог: 90 раз(а)
IllusionMH пишет:
Тут уже скорее если смогли скомпрометировать файлы кэша, то нужно искать имеющиеся уязвимости.
Например, когда кэш хранится в /tmp директории на шаред хостинге.
esterio
Отправлено: 24 Февраля, 2014 - 15:32:41
Активный участник
Покинул форум
Сообщений всего: 5025
Дата рег-ции: Нояб. 2012 Откуда: Украина, Львов
Помог: 127 раз(а)
я еще раз говорю, код в не класса с шаблона не попадет. только если кэш файл вручную самому не изменить
Покинул форум
Сообщений всего: 329
Дата рег-ции: Апр. 2011
Помог: 7 раз(а)
IllusionMH пишет:
Тут уже скорее если смогли скомпрометировать файлы кэша, то нужно искать имеющиеся уязвимости.
Вот эта фраза заставила меня переформулировать вопрос. Скорее, его нужно поставить так.
Хранить кэш в классах - это элегантно и быстро. Но хранить кэш в сериализованном каким-либо образом виде, вероятно, безопаснее. При этом при десериализации можно избежать запуска измененного кода, но, безусловно, потерять в производительности. Дак вот, если принять за условие, что TWIG или другой подобным образом работающий шаблонизатор сам не пропускает в кэш чужой код, но он попадает в кэш через другие дырки, то при сериализованных шаблонах появляется дополнительная защита, но падает, как я уже сказал скорость обработки. И вопрос в том стоит ли париться в этом случае или такая вставка кода, если она случилась, безусловно не будет отнесена на счет шаблонизатора.
Условно, не получим в итоге фразы, что это шаблонизатор виноват, потому что вот если бы он хранил кэш в сериализованном виде, то такого бы не произошло?
Ch_chov
Отправлено: 24 Февраля, 2014 - 15:48:03
Постоянный участник
Покинул форум
Сообщений всего: 2121
Дата рег-ции: Июль 2008 Откуда: из города
Помог: 90 раз(а)
IllusionMH пишет:
проблема шаред хостингов и настроек. Разве нет?
Нет, проблема именно в разработчиках, которые используют дефолтную tmp директорию, для хранения "небезопасных" файлов. В unix системах /tmp должна быть доступна для записи и чтения. От этого может зависеть роботоспособность некоторых программ. (Добавление)
MAXUS пишет:
Но хранить кэш в сериализованном каким-либо образом виде, вероятно, безопаснее. При этом при десериализации можно избежать запуска измененного кода, но, безусловно, потерять в производительности.
Если кто то получил доступ к файловой системе сервера, то метаться уже поздно. Какой смысл вставлять код в компилированные шаблоны, которые будут перезаписаные после сброса кэша? Ведь на сервере наверняка, есть куча других php файлов.
MAXUS
Отправлено: 24 Февраля, 2014 - 16:04:15
Посетитель
Покинул форум
Сообщений всего: 329
Дата рег-ции: Апр. 2011
Помог: 7 раз(а)
Ch_chov пишет:
Если кто то получил доступ к файловой системе сервера, то метаться уже поздно. Какой смысл вставлять код в компилированные шаблоны, которые будут перезаписаные после сброса кэша? Ведь на сервере наверняка, есть куча других php файлов.
Логично. Но суть в следующем. По идее на все можно поставить запрет на запись, а на кэш нельзя (ну по определению). Скажем, получил ты доступ к исполнению php кода через иньекцию, но все вокруг только для чтения. В таком случае изменить можно только кэш. Я так рассуждаю. Поправьте, если не прав.
Попутный вопрос. Средствами php, насколько я понимаю, атрибуты файлов менять можно. А при любых настройках? Просто если можно, то тогда в итоге, действительно, по большому счету все равно какие атрибуты стоят на файлах. И, действительно, проще искать варианты размещения shell в постоянных скриптах, а не в кэше.
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.