Проблемы безопасности с разрешениями на запись в Web.config

В настоящее время у меня есть сайт PHP, работающий на сервере IIS7.5.

Я использую встроенный инструмент для перезаписи URL-адресов для IIS в файле web.config.

У моего администратора CMS есть возможность разрешить пользователю писать свои собственные файлы. Итак, моему инструменту администратора, написанному на PHP, необходимы права на запись и изменение для IUSER, чтобы PHP мог изменить файл. Однако я подумал, что это, вероятно, не очень хорошая практика для безопасности, поэтому я решил переместить перезапись в файл rewrite.config, на который ссылается web.config. Затем я даю права на запись / изменение файлу перезаписи, а не файлу web.config.

Единственная проблема заключается в том, что IIS кэширует внешний файл перезаписи и не перезагружает его, если дата последнего изменения web.config не кэшируется. Я могу вручную заставить сервер перезагрузить мой файл rewrite.config, открыв web.config в текстовом редакторе, добавив пробел или что-то в этом роде, а затем нажав «Сохранить», сервер затем замечает, что дата последнего изменения изменилась, а затем перезагружает файл перезаписи с новой переписью.

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

Я узнал, что могу вызвать сенсорную функцию в PHP в файле web.config, и это решает мою проблему, поскольку изменяет дату последнего изменения в файле web.config. Однако для того, чтобы касание работало, PHP необходимо, чтобы IUSER имел для этого права записи, но не мог изменять разрешения.

Итак, наконец, мой вопрос ... с точки зрения безопасности, можно ли оставить web.config с разрешениями IUSER на чтение и запись, но не на изменение? Или это все еще проблема безопасности.

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


person TroySteven    schedule 03.04.2013    source источник


Ответы (1)


Отвечая на свой вопрос. Лучше всего не давать разрешения I_USER файлу web.config. В итоге мы переписали наш код, чтобы он больше не требовался.

person TroySteven    schedule 05.04.2019