Web.config上写权限的安全问题

Question

我目前有一个运行在IIS7.5服务器上的PHP站点。

我在web.config中使用为IIS构建的url重写工具。

我的CMS管理员有能力允许用户编写自己的重写。因此，我用PHP编写的管理工具需要IUSER的write modify权限，以便PHP修改文件。但是，我认为对于安全性来说，这可能不是一个好的实践，所以我决定将重写移到web.config引用的rewrite.config文件中。然后，我将写入/修改权限授予重写文件，而不是web.config。

唯一的问题是IIS会缓存外部重写文件，除非缓存web.config的上次修改日期，否则不会重新加载它。我可以手动强制服务器重新加载我的rewrite.config文件，方法是在文本编辑器中打开web.config，添加一个空格或其他内容，然后单击保存，服务器随后会注意到上次修改日期已更改，然后使用新的重写重新加载重写文件。

我不能永远这样做，我需要我的管理工具来允许用户添加他们自己的重写，而不必在他们的重写生效之前打电话给我在web.config中进行更改。

我了解到，我可以在web.config文件上调用PHP中的touch函数，这解决了我的问题，因为它更改了web.config文件的最后修改日期。但是，为了让touch正常工作，PHP需要IUSER拥有写权限，而不是修改权限。

最后我的问题是..。从安全角度来看，是否可以将web.config保留为具有读写权限但不具有修改权限？或者这仍然是一个安全问题。

如果是这样的话，我为这个站点创建了哪些漏洞？而且，我如何才能改变我的方法，不让自己暴露在这些漏洞中？

Answer 1

回答我自己的问题。最佳实践是避免向web.config授予I_USER权限。我们最终重写了我们的代码，不再需要这个。