我的 web 应用程序在 windows server 2003 下的 IIS 6.0 中运行,我们都知道在这种情况下,IIS 使用用户帐户“网络服务”。
我碰巧必须允许某些用户在我的网页上执行某些操作,而该操作需要管理员权限。
对我来说最懒惰的解决方案似乎是将“网络服务”添加到管理员组,它确实有效。
我的问题是,这个解决方案有多危险,它会以什么方式危及我的 Web 服务器的安全性?
我的 web 应用程序在 windows server 2003 下的 IIS 6.0 中运行,我们都知道在这种情况下,IIS 使用用户帐户“网络服务”。
我碰巧必须允许某些用户在我的网页上执行某些操作,而该操作需要管理员权限。
对我来说最懒惰的解决方案似乎是将“网络服务”添加到管理员组,它确实有效。
我的问题是,这个解决方案有多危险,它会以什么方式危及我的 Web 服务器的安全性?
这通常是“一个坏主意”。如果这是面向公众的服务器,那么这是一个非常糟糕的主意。
您应该做什么,这就是我们处理此类问题的方式,将您需要在另一个进程(例如具有提升的权限的 Windows 服务)中执行的特定管理任务沙箱化。
然后,我们在 Windows 服务中托管一个远程处理服务器,并通过命名管道或 TCP/IP(如果机器对机器并且这是通过后端专用网络)与服务通信。
有关更多信息,请参阅我为其他用户留下的关于类似问题的答案:
更好的方法是永远不要在 Web 应用程序和 Windows 服务之间进行直接通信,而是通过诸如作业或消息队列之类的中介。您的低权限应用程序请求执行管理任务,您的提升权限服务从队列中读取这些任务并执行它们。
在这两种情况下,您都应该确保您不会过分强调每项任务的责任。即确保如果任务是在服务器上创建一个新的 Windows 帐户,那么不要让该新帐户获得比它需要的更多的权限。
如果我要编写一些需要框级管理员的 Web 功能,我会在自己的应用程序池中创建它自己的应用程序,尽可能紧密地锁定该应用程序,为该应用程序池提供一个命名帐户(域资源,如果在 Active Directory 上),然后在该框上授予该帐户管理员权限。将其保存在自己的应用程序池中可以有效地将其锁定在常规应用程序之外。
NT 授权/网络服务与您机器上的大量内容进行交互。我想不出任何充分的理由来获得网络服务管理员权限。
在任何情况下都不要这样做。
如果您将网络服务添加到管理员组,那么所有访问您的 Web 应用程序的匿名用户将默认为管理员,并且潜在的损害是巨大的。
根据你的问题
我碰巧必须允许某些用户在我的网页上执行某些操作,而该操作需要管理员权限。
很好 - 在该网页上使用 Windows 身份验证并使用户成为普通的 Windows 管理员。现在,他们和所有其他管理员可以执行您设置的任务。