使用 .net 异常作为 WCF 故障契约是否存在安全风险？
在摆弄 WCF 错误契约时，我希望可以在错误中将自定义异常继承树重用为 TDetail。在开始工作后，我开始思考这个问题（是的，在完成工作后，你知道这是思考的最佳时机）。我注意到客户端获取了序列化为 TDetail 的异常的完整堆栈跟踪。
现在我想这就是您不打开
While fiddling with WCF fault contracts, I was hoping I could reuse my custom Exception inheritance tree as TDetail in my Faults. After getting this to work, I started thinking this through (yes, after doing the work, you know that's the best time to think). And I noticed that the client gets the full stacktrace of the exceptions that are serialized as TDetail.
Now I was thinking that this is the exact reason you don't turn on <servicedebug includeExceptionDetailInFaults="true" />. But I'm not sure. Would it be a security risk for me to use my exceptions as TDetail? And what are my other options?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如前所述，这可能会带来安全风险，因为它会向外界泄露有关您内部系统的更多信息。但是，TDetail 可以是任何内容，因此您可以创建新的异常选项，保留您想要保留的消息和有趣的异常信息，但清除堆栈跟踪等安全数据，然后仅将您批准的那些部分序列化给客户端。
As mentioned, it can be a security risk in that it reveals more about your internal systems to the outside world. However, the TDetail can be anything, so you could create new exception options that keep the messages and interesting exception information youd like to keep but clears out secured data like the stack trace and then serializes just those parts you approve of to the client.
暴露堆栈跟踪并不是那么大的安全风险，但可能会给攻击者提供有关您系统的更多信息（数据库、库等）。因此，我认为您应该在生产环境中提供详细信息，但它们在调试时很有帮助。
Exposing stack trace isn't so big security risc but potentialy can give atacker more information aboute you system (database, libs, etc. ). So in my opinion you should turn details of in production environment but they are a great help when debugging.
取决于谁是您服务的消费者。如果假设您要将其向外界开放，那么将这些详细信息传递给服务的客户端并不是一个好主意，因为它让服务的消费者了解可能导致安全漏洞的事情。但是，如果您可以说在内部使用它并管理得很好，并且您希望他们能够如何利用这些细节做一些事情，那么这是您的决定，因为最终它可能位于不向外部开放的防火墙后面我猜，外面的世界和由管理员控制的网络上。
Depends on who are the consumers of your service. If lets say you are opening it to the outside world, it would not be a good idea to pass these details to the clients of the service, because it gives the consumers of the service an idea about things that could cause a security breach. But if you are lets say using it internally and managed well and you want them to some how be able to do some thing with these details, then its your call, cause at the end of the day its probably behind a firewall not open to the outside world and on a network being controlled by an administrator Im guessing.