System.Diagnostics 将允许用户在 IIS7 中终止自己的进程
IIS7中的托管客户可以使用asp.net和System.Diagnostics来列出所有系统的进程ID。他们还可以杀死属于自己的应用程序池的应用程序。对于共享托管环境来说，IIS7 似乎存在很大的安全问题。关于如何阻止普通用户访问 System.Diagnostics 有什么建议吗？如何限制只有管理员才能访问？
Hosted customers in IIS7 can use asp.net and System.Diagnostics to list all the system's process ID. They can also kill the ones that belong to their own application pools. Seems like a big security problems in IIS7 for shared hosting environment. Any suggestions on how to prevent normal users from accessing System.Diagnostics? How to limit it to administrators only?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
与 Windows 2003 和 IIS6 不同，许多共享 Windows 2008/IIS7 托管环境为其客户提供专用应用程序池和完全信任。
虽然客户可能能够启动和终止他们自己的进程（包括他们自己的工作进程），但只要网站运行的帐户的身份被锁定，那么就不会造成真正的损害。另外，对于拥有不断终止自己的应用程序池的代码的客户来说，有什么好处（除了强制重新启动工作进程以允许在需要重新加载某些设置时触发
Application_Start类型事件）那里）？我为一个共享托管服务商工作，我们实际上为客户提供了通过我们的管理系统启动、停止和回收其专用池的能力，他们在代码中所做的一切几乎都是相同的事情。
最糟糕的情况是，客户启动了一个消耗大量内存或过多 CPU 的进程（但随后，即使他们自己的 ASP.NET 代码也可能会因为同样的情况而失控）。我们持续监控服务器是否存在此类异常行为，并可以在收到警报后 2-3 分钟内找到肇事者。最终用户将收到友好的警告，并被告知不要再这样做，如果他们这样做，他们的网站将立即关闭。
唯一一次我担心托管服务商是否以完全信任的方式运行共享池，但如果他们这样做，那么他们就需要克服其他所有安全问题，进程终止将是他们最不担心的。
Unlike with Windows 2003 and IIS6, many shared Windows 2008/IIS7 hosting environments provide their customers with dedicated application pools and Full Trust.
Whilst customers may be able to launch and kill their own processes (including their own worker processes), provided that the identity of the account that the site runs under is locked down then no real harm can be done. Also what would be the benefit to a customer having code that constantly kills their own application pool (other than to force a restart of a worker process to allow
Application_Starttype events to fire if you need to reload some settings there)?I work for a shared hoster, we actually provide customers with the ability to start, stop and recycle their dedicated pools via our admin system, all they would be doing in code is pretty much the same thing.
The worst that can happen is that a customer launches a process that consumes large amounts of memory or an excessive amount of CPU (but then even their own ASP.NET code can run away out of control doing the same). We monitor our servers continuously for such anomalous behaviour and can track down the culprit within 2-3 minutes of being alerted. The end user will get a friendly warning and told not to do this again, if they do then their site is instantly shut down.
The only time I'd be worried if the hoster was running shared pools at full trust, but if they're doing that then they have a whole other security headache to overcome, process killing would be the least of their worries.