Forums / National / Russian / Тех. поддержка / Экстраполе file - потенциальная уязвимость?

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

Попробую объяснить.
1. Механизм Экстраполей — это возможность создать дополнительное поле данных для какой либо сущности, используемой системой (ядром или расширением). Дополнительное поле будет присутствовать у всех элементов данной сущности. Т.е. если мы создаем дополнительное поле данных для страницы, то у всех страниц будет присутствовать это дополнительное поле. В твоем случае, использовать доп.поля для хранения доп.данных у единичного элемента — логически (и идеологически) не верно. Это, во-первых, избыточно — поля данных создаются у всех пользователей, хотя реально используются только у одного (у админа). Во-вторых, мы дополнительно получаем необходимость разруливать кто из пользователей может этим пользоваться, а кто нет (то с чем ты столкнулся), хотя экстраполя изначально предназначались для равнозначного использования со всеми элементами.

2. Использование условий в шаблонах, это, в принципе, своего рода костыль (точнее не правильное испольование ).  При разработке правильных приложений алгоритмическая логика должна быть максимально отделена от (логики) отображения. Т.е. в идеале все должно стремится к варианту проектирования по типу MVC (или аналогичному). Единственно правильная логика (условия) в шаблонах, которые там «правильно» использовать, это логика отображения конечных данных. Т.е., если простыми словами, варианты оформления данных (например каким цветом вывести счетчик взависимости от чисел на нем, или какую иконку пользователя вывести в зависимости от того залогинен ли он). У тебя, в данном случае, в шаблоне логика уровня приложения (которая влияет на его функционал).

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

Отвечая на поставленные вопросы:

• нужна ли проверка? Да нужна, если ты хочешь решить поставленную задачу, т.к. используемые тобой механизмы (экстраполя и шаблоны) эту задачу не решают.
• на сколько безопасно… очень условная шкала. Есть ряд методов, которые позволяют угрозу снизить, но нет «серебрянной пули». Дело тут не в Cotonti или его механизмах, а дело в принципе. Как только ты позволяешь грузить что-то кому-то кроме себя (админа) это уже потенциальная уязвимось.

Подводя итог, тут проблема в не правильном подходе. Для решения этой задачи, да, нужен отдельный плагин, но который берет на себя весь цикл: получение данных, обработка, хранение. Причем лучше использовать хук tools, чтобы страница ввода была в админской части.

#41061 Roffun:

#41059 Macik:

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

Отвечая на поставленные вопросы:

• нужна ли проверка? Да нужна, если ты хочешь решить поставленную задачу, т.к. используемые тобой механизмы (экстраполя и шаблоны) эту задачу не решают.
• на сколько безопасно… очень условная шкала. Есть ряд методов, которые позволяют угрозу снизить, но нет «серебрянной пули». Дело тут не в Cotonti или его механизмах, а дело в принципе. Как только ты позволяешь грузить что-то кому-то кроме себя (админа) это уже потенциальная уязвимось.

А рзве у пользователя есть другие варианты кром проверок в шаблоне типа?
<!-- IF  {PHP.usr.isadmin} -->{ЭКСТРАПОЛЕ}<!-- ENDIF -->

Если да, то где они написаны ?  При создании экстраполя ничего подобного не пишется..

Экстраполя сами по себе не предназначены для «выборочного» использования. Поэтому никойкой дополнительной проверки нет. Расчет на то, что они создаются для всех пользователей и для всех элементов сущности к которой привязаны.

Я понял твою логику, она верна если цель - создание плагина, с отдельным загрузчиком. Но такой цели не было. 

Была одна цель :  создать автоматически экстраполе файл, которое в свою очередь создает загрузчик проверочных файлов типа html или txt в корень сайта для подтверждения прав с последующим удалением.

Да, в таком виде цель была достигнута. Я лишь предупредил о том, что такое использование может быть опасно.

Задача:  решить эту проблему средствами доступными обычному пользователю, у которого просто есть сайт на Cotonti, он ничего не знает о потенциальных уязвимостях и тем более разработках, он просто хочет получить возможность загрузить проверочный файл, и после удалить его не используя ftp.

Именно потому, что конечный пользователь ничего не знает — задача разработчика сайта/плагина максимально подумать за него и сделать «защиту от дурака» или умышленного вредительства. (А удалить можно тоже через механизм экстраполей.)

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

Какой ответ в таком случае получил бы пользователь ?

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

Значит нужно создать экстраполе file, и разместить его в шаблоне. При создании поля подсказка указывает, что теги будут работать в:

• users.profile.tpl: {USERS_PROFILE_XXXXX}, {USERS_PROFILE_XXXXX_TITLE};
• users.edit.tpl: {USERS_EDIT_XXXXX}, {USERS_EDIT_XXXXX_TITLE};
• users.details.tpl: {USERS_DETAILS_XXXXX}, {USERS_DETAILS_XXXXX_TITLE};
• user.register.tpl: {USERS_REGISTER_XXXXX}, {USERS_REGISTER_XXXXX_TITLE};
• forums.posts.tpl: {FORUMS_POSTS_ROW_USERXXXXX}, {FORUMS_POSTS_ROW_USERXXXXX_TITLE};

В users.profile.tpl - как раз то что нужно. Поле создано, подсказка показывает где можно использовать, указывает нужные теги, остается только в шаблон их вставить. Никаких предупреждений система не выдает, значит можно пользоваться, остается только разместить в шаблоне.

Все верно. И тут НЕ сказано добавьте «условий в шаблон», чтобы скрыть какие-то поля у части пользователей. Потому, что использование экстраполя подразумевается равнозначным для всех пользователей без исключения.

Вопрос: что делать пользователю в такой ситуации ?  не пользоваться экстраполем типа file вообще потому что это уязвимость ?

если да, то почему оно доступно для создания, и еще совет куда вставить дается, никаких предупреждений.

Потому, что механизм универсален. И надо включать голову, если мы хотим использовать его несколько не стандартно. 
Это как «грабли» — можно траву убирать, а можно и черенком глаз высадить. :)

---

Плагин появился только для создания экстраполя. Без использования плагина можно все это проделать из админки самостоятельно, дальше работает механизм экстраполя file. Он вообще ничего не делает кроме создания экстраполя.

Рассуждать о потенциальных угрозах можно в теории, но на практике меня интересует ответ на один - единственный вопрос:

Для чего предназначено экстраполе file для cot_users ?

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

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

Проверка на сервере решит вопрос безопасности ?

например:

если на хук extrafields.import.file.first подцепить:

global $usr;
if($usr['isadmin']){
cot_error('Вы не можете загружать проверочные файлы', $inputname);
}

Этого будет достаточно ?

В таком виде будет работать не правильно.  Дал комментарии вна гитхабе

Добавлено 10 минут спустя:

#41059 Macik:

Подводя итог, тут проблема в не правильном подходе. Для решения этой задачи, да, нужен отдельный плагин, но который берет на себя весь цикл: получение данных, обработка, хранение. Причем лучше использовать хук tools, чтобы страница ввода была в админской части.

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

Потому, что в таком виде (что создание поля руками, что создание поля плагином) вело к возможной уязвимости сайта.

Кстати с самого начала в описании к плагину было:

Важно:  плагин создавался из рассчета на одноразовые проверки, по принципу загрузил проверил удалил. На данный момент в нем  два поля, это значит что одновременно может быть загружено максимум два файла. 

Это значит что постоянное нахождение на сервере файла не входило в планы, а только загрузка - проверка - удаление. В том числе удаление плагина (а значит поля). 

Добавлено 1 час спустя:

==========================================

Добавил проверку , является ли пользователь админом.

Цель создания плагина указана выше - автоматическое создание экстраполя. 

Благодарю за конструктивный развернутый ответ, Macik, в любом случае информация полезная.

Всегда рад. Моя задача, как раз, не «настучать по рукам», а показать подводные камни и объяснить.