是System.Security.Principal.WindowsIdentity 合理的从安全的被黑客攻击，这样的情况下，我从Thread.CurrentPrincipal's 身份或WindowsIdentity.GetCurrent()其中有真为 IsAuthenticated 给我的装配虚假的身份信息？当然，没有什么，完全是防篡改的，但考虑到微软.Net的承诺和依赖，我预计关键的API，如这是的锁定的硬的，不易篡改。那是我的一部分假设是否正确？

Is System.Security.Principal.WindowsIdentity reasonably secure from being hacked such that an instance I get from Thread.CurrentPrincipal's Identity or WindowsIdentity.GetCurrent() which has true for IsAuthenticated gives my assembly false identity information? Nothing, of course, is completely tamper-proof, but given Microsoft's commitment to and reliance on .Net, I would expect critical APIs like this to be Locked Down Hard and difficult to tamper with. Is that a valid assumption on my part?

我的目标是要提供合理的最佳实践SSO在我的组装。如果Windows本身受到损害，这是在我的掌握，但如果（例如），这是一个简单的事情对于一个应用程序与我的组装喂我虚假信息联系起来，这将是对我没有做尽职调查。这是无知的大面积适合我。

My goal here is to provide reasonable best-practices SSO in my assembly. If Windows itself is compromised, that's out of my control, but if (for instance) it's a straightforward matter for an app linking with my assembly to feed me false information, that would be on me for failing to do due diligence. This is a big area of ignorance for me.

需要明确的是，我在寻找硬信息，而不是现成的，袖口的意见。因此，公布的漏洞，或已证实使用的WindowsIdentity 构造中，将骗我的code等，或在这是一个有效的假设的一面的方式，固体物品备份它，依赖它已知用途等，我还没有很多运气找到他们，但我已经包括了我所发现远远低于下分隔。

To be clear, I'm looking for hard information, not off-the cuff opinions. So, published exploits, or demonstrated use of a WindowsIdentity constructor in a way that would trick my code, etc. Or on the "that's a valid assumption" side, solid articles backing it up, known uses relying on it, etc. I haven't had a lot of luck finding them, but I've included what I've found so far below under the divider.

下面是我打算如何使用的WindowsIdentity ：

Here's how I intend to use WindowsIdentity:

using System.Security.Principal;
using System.Threading;
// ...

// I only want Windows-authenticated users
WindowsIdentity identity = Thread.CurrentPrincipal == null
    ? null
    : Thread.CurrentPrincipal.Identity as WindowsIdentity;
SecurityIdentifier sid;

// I can't imagine how an authenticated account would be anonymous, but...
if (identity != null && identity.IsAuthenticated && !identity.IsAnonymous) {
    // SSO success from thread identity
    sid = identity.User;
    // ...check that that SID is allowed to use our system...
} else {
    identity = WindowsIdentity.GetCurrent();
    if (identity != null && identity.IsAuthenticated && !identity.IsAnonymous) {
        // SSO success from current Windows user
        sid = identity.User;
        // ...check that that SID is allowed to use our system...
    } else {
        // SSO fail
    }
}

这是一个DLL组件＆NBSP;＆mdash;可悲的是我们坚持.Net的3.5＆NBSP;＆mdash;它提供了一个公共API资源可以由用户的权利的限制。它可能在桌面应用程序中使用，或者与Windows身份验证的ASP.Net IIS应用程序（ASP.Net设置在一个Thread.CurrentPrincipal中的WindowsIdentity 实例.Identity 当使用Windows身份验证;我们不支持其他种类的IIS身份验证$ P $的psently）

This is in a DLL assembly — sadly we're stuck on .Net 3.5 — that provides a public API to resources that may be restricted by user rights. It might be used in desktop apps, or in an ASP.Net IIS app with Windows authentication (ASP.Net sets a WindowsIdentity instance on Thread.CurrentPrincipal.Identity when using Windows auth; we don't support other kinds of IIS auth presently).

我可以合理相信从的WindowsIdentity 实例的SID从那些声称像要被认证的来源？

Can I reasonably trust a SID from a WindowsIdentity instance from those sources claiming to be authenticated like that?

它没有想到我不知道这是否是好的（ DOH！的），直到this问题用户 LC。提出的关切，大会将容易被欺骗恶意应用程序，链接它和伪造的信息。他没有任何具体的证据指向了为什么这可能是一个显著的关注，不过，因此这个问题。

It didn't occur to me to wonder if that was okay (doh!) until in this question user lc. raised a concern that the assembly would be susceptible to being tricked by a malicious app that linked with it and "faked" that information. He didn't have any specific evidence to point to for why that might be a significant concern, though, hence this question.

什么（略）我到目前为止已经发现：

What (little) I've found so far:

这个答案使得索赔

您可以相信，当前的的WindowsIdentity 是谁也说，这是，只要你可以相信任何给定数据的应用程序。

You can trust that the current WindowsIdentity is who it says it is, insofar as you can trust any given piece of data in your application.

这本书的黑客入侵code 的声称ASP.Net需要一个的WindowsIdentity 来与要求进行文件authorizaton检查，如果为true则似乎是一个非常坚实的基础，说微软，至少，在考虑相关它足够好了。

The book Hacking the Code claims that ASP.Net requires a WindowsIdentity to be associated with a request when doing file authorizaton checking, which if true seems like a fairly solid basis for saying Microsoft, at least, considers it good enough.

我可以找到大量的人愉快地使用他们的code中的的WindowsIdentity 信息的例子，但他们大多不问的问题无论他们是安全的。这里有一个的含义的，但是......

I can find plenty of examples of people happily using the WindowsIdentity information in their code, but most of them don't ask the question of whether they're secure. There's an implication, but...

推荐答案

您不能信任来自 Thread.CurrentPrincipal中一，没有。没有什么能阻止code。在完全信任运行从欺骗了。

You can't trust the one from Thread.CurrentPrincipal, no. There's nothing to stop code running in full trust from spoofing it.

我能够欺骗它在我的环境是这样的：

I was able to spoof it in my environment like this:

var admin = new WindowsIdentity(@"Administrator");
var princ = new WindowsPrincipal(admin);
System.Threading.Thread.CurrentPrincipal = princ;

...你调用code之前。在我的机器，创建的WindowsIdentity 对象 IsAuthenticated 为真和 IsAnonymous 假的，所以，当然，你的code提取我的域管理员的SID。

...before invoking your code. On my machine, the created WindowsIdentity object has IsAuthenticated as true and IsAnonymous false, and so, of course, your code extracts my domain administrator's SID.

这并不适用于所有环境下工作，但这应该，只要运行code有足够的权限来使用反射：

That doesn't work in all environments, but this should, provided that the running code has enough permissions to use reflection:

var ident = WindowsIdentity.GetCurrent();
Thread.CurrentPrincipal = new WindowsPrincipal(ident);
var userSid = ident.User;

var fakeSid = new SecurityIdentifier("S-1-3-0");

typeof (WindowsIdentity).GetField("m_user",
  BindingFlags.Instance | BindingFlags.NonPublic).SetValue(ident, fakeSid);

（同样，致电code做过的事情。）

(Again, done before calling your code.)

基本上，没有什么可以阻止两件code运行在完全信任同一进程中，从躺着到对方。

Basically, there's nothing to stop two pieces of code running under Full Trust within the same process from lying to each other.