问：

我们的 .NET Framework C# 应用程序由两部分组成：客户端（未提升）和服务（提升）。客户端和服务之间的通信通过命名管道进行。每当要执行提升的任务时，客户端（命名管道客户端）始终与服务（命名管道服务器）进行通信。通信采用 JSON 字符串的形式。需要保护此通信，以便服务不会被欺骗代表攻击者执行提升的任务。@Xecrets 该服务是客户端执行提升任务的一种特权帮助程序。该服务具有一些强大的功能，例如将文件复制到 Program Files、安装 MSI 以及运行 .reg 注册表文件。

服务器端已经采取了一些安全措施：

1. Pipe Security 对象具有一些安全措施：

PipeSecurity pipeSecurity = new PipeSecurity();
var id = new SecurityIdentifier(WellKnownSidType.AuthenticatedUserSid, null);

// Allow read and write access to the pipe from different user sessions
pipeSecurity.SetAccessRule(new PipeAccessRule(id, PipeAccessRights.ReadWrite, AccessControlType.Allow));
            
// Grant Service user instance full control.
pipeSecurity.AddAccessRule(new PipeAccessRule(System.Security.Principal.WindowsIdentity.GetCurrent().User, PipeAccessRights.FullControl, AccessControlType.Allow));
           

2. 该服务检查尝试连接到名为管道的服务的进程 exe 的路径。仅当客户端进程位于白名单路径上时，服务才接受连接。

问题

但是，存在另一个漏洞的风险，即 DLL 注入。如果将 DLL 注入到客户端进程中，则当 DLL 尝试连接到名为管道的服务时，DLL 的路径似乎与客户端应用的路径相同。这会欺骗服务，并且某些任意命令可以从注入的 DLL（恶意）传递到服务。这可能会导致权限提升。如何确保只有客户端应用才能与服务通信？

相关

也许这是相关的，我不确定：从命名管道获取客户端用户令牌

我们是否应该尝试保护命名管道以避免注入的 DLL 与我们的服务进行通信，还是应该尝试完全使用不同的 IPC，例如服务契约？

脑海中的想法

尝试优化以下想法来解决此问题：

1. Microsoft安全和访问权限 （https://learn.microsoft.com/en-us/windows/win32/ipc/named-pipe-security-and-access-rights） 这看起来有点难以理解。另外，我不确定这是否真的能解决我的问题。

2. 考虑在客户端和服务之间的通信中使用非对称加密。但这种方法的挑战在于，在客户端和服务之间安全地分发公钥和私钥似乎是不可能的。如果客户端在未提升的情况下运行，则客户端肯定无法将公钥存储在安全位置。因此，攻击者可以很容易地修改公钥并提供自己的公钥来欺骗服务。