ASP.NET 诊断页面的安全性
我正在考虑为 ASP.NET 应用程序创建一个诊断页面，该页面主要供管理员使用，以获取有关应用程序的更多信息以诊断问题。
该页面可能包含的信息示例：
- System.Environment.MachineName（在网络场场景中可能有用）
- System.Environment.Version
- Environment.UserName
- 数据库名称
- 当前用户的会话 ID
此页面上的某些信息可能对安全性敏感看法。 如果您以前访问过此类页面，那么您对该页面的访问采取了何种安全措施？ 。
编辑：
我应该添加 - 有时，以特定（即真实）最终用户身份登录时查看此页面可能会很有用。例如，假设只有在以特定用户身份登录时才能重现问题。能够查看该用户的诊断页面可能会很有用。例如，了解当前会话 ID 可能有助于调试。
编辑2：
我开始认为这个诊断页面实际上应该是两个不同的页面。一种显示对所有用户都相同的内容（例如数据库名称、CLR 版本），另一种显示可能因会话而异的内容（例如浏览器信息、会话 ID）。 然后您可以进一步锁定首页的安全性。
I'm thinking of creating a diagnostics page for an ASP.NET app, which would be mostly intended for admin use to get more information about the application for diagnosing problems.
Examples of the info the page might have :
- System.Environment.MachineName (might be useful in web farm scenarios)
- System.Environment.Version
- Environment.UserName
- database name
- current user's session ID
Some of the info on this page might be sensitive from a security perspective.
If you've done this sort of page before, what sort of security did you put on access to this page ? .
EDIT :
I should add - occasionally it might be useful to see this page whilst logged in as a specific (i.e. real) end user. e.g. say a problem can only be reproduced when logged in as a particular user. Being able to see the diagnostics page for that user might be useful. e.g. knowing the current session ID might be helpful for debugging.
EDIT 2 :
I'm starting to think that this diagnostics page should in fact be two different pages. One to display stuff which is the same for all users (e.g. database name, CLR version), and another for stuff which can vary by session (e.g. browser info, session ID).
Then you could lock down security more for the first page.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，我之前添加过此类页面（并且发现它很有用）。安全性非常简单：该页面包含一个密码表单。服务器端代码根据配置的值检查此密码，如果正确，则显示真实内容并在用户会话中设置一个值，表明他们已通过开发人员身份验证，以便接下来不会再次提示他们时间。
我想，由于该页面的 URL 没有在任何地方发布，所以隐匿性也有一点安全性。
我还小心翼翼地避免在页面上透露任何真正的敏感信息。例如，它允许查看我们的应用程序配置值，但屏蔽了其中包含“密码”的任何内容 - 嘿，如果我们真的想查看密码，我们可以打开到服务器的远程桌面会话。
Yes, I've added this sort of page before (and found it useful). The security was pretty simple: the page contained a password form. The server-side code checked this password against a configured value and, if correct, displayed the real content and set a value in the user's session to say that they've been authenticated as a developer, so that they're not prompted again next time.
I suppose there was also a little security by obscurity, since the URL of the page wasn't published anywhere.
I was also careful not to reveal anything really sensitive on the page. For example, it allowed viewing our application config values, but masked out anything with "password" in it - hey, if we really want to see the password we can open a remote desktop session to the server.
您还可以通过其他几种方法来执行此操作：
如果您的 Web 应用程序具有用户身份验证，请通过检查用户是否被标记为管理员或属于某种管理员角色来限制对此页面的访问。
使用简单的
if (Request.IsLocal) ...类型检查，尽管这样做的缺点是您仍然必须连接到服务器并在本地浏览网站 - 这可能并不总是有可能。但是，这仍然具有能够轻松查看关键系统设置的好处。就我个人而言，我使用了两种方法的组合，其中本地请求始终允许访问，而非本地请求需要管理员用户 - 例如。
if (!Request.IsLocal && !IsAdminUser()) 抛出 new SecurityException()。另外，我同意 Evgeny 的观点 - 请注意不要泄露此页面上任何真正敏感的内容（例如应用程序连接字符串或密码）。
There's also a couple of other ways you could do this:
If your web application has user authentication, restrict access to this page by checking that the user is flagged as an administrator or belongs to some kind of admin role.
Use a simple
if (Request.IsLocal) ...type check, though the downside of this is that you still have to connect to the server and browse the website locally - which might not always be possible. However, this does still have the benefit of being able to easily view key system settings.Personally, I've used a combination of both methods where a local request always allows access, and non-local requests require an admin user - eg.
if (!Request.IsLocal && !IsAdminUser()) throw new SecurityException().Also, I'm in agreement with Evgeny - be careful not to reveal anything really sensitive on this page (such as application connection strings or passwords).
使用表单身份验证并设置一两个有权访问该页面的用户。这样，您就可以在站点部署后更改密码并撤消访问权限。
use forms authentication and setup a user or two with access to that page. that way you can change passwords and revoke access once the site is deployed.
听起来您想要一个针对错误页面的强大解决方案。我会看一下像 Elmah 这样的开源项目 (http://code.google.com/p /elmah/），这是一个包含可配置安全性的强大错误页面的好例子。为了给您一个想法，这里有一个 关于配置 Elmah 的帖子将引导您完成安全设置。我测试过的安全性允许我使用我的域凭据登录。
It sounds like you want a robust solution for your error page. I would take a look at open source projects like Elmah (http://code.google.com/p/elmah/) for a good example of a robust error page which includes configurable security. To give you an idea, here is a post on configuring Elmah which takes you through setting up the security. The security I have tested allows me to use my domain credentials to login.