防止跨进程 SendMessage 调用答案

【问题标题】：Preventing cross-process SendMessage Calls防止跨进程 SendMessage 调用
【发布时间】：2012-08-06 18:02:08
【问题描述】：

假设我有一个带有按钮的 Windows GUI 应用程序。我可以通过使用带有BM_CLICK 作为调用参数的sendMessage winapi 调用来模拟对该按钮的单击。

现在，从安全角度来看，我不希望这种情况发生。即我的目标进程应该忽略来自另一个进程的 sendMessage 调用。有没有规定可以做到这一点？一种验证 sendMessage 调用的方法？

编辑：换句话说，我怎样才能防止启动器、TurnitOn http://www.raymond.cc/blog/how-to-enable-and-access-disabled-grayed-out-buttons-windows-and-checkboxes/ 等应用程序访问不应该由用户访问的功能？

【问题讨论】：

这就是为什么有 UIPI 来阻止低权限应用程序向高权限应用程序发送消息的原因。 (msdn.microsoft.com/en-us/library/bb625963.aspx) 但是不，您通常无法分辨消息来自何处。毕竟，有些消息来自系统。
谢谢！ UIPI 是我不熟悉的东西。但根据该文件，UIPI 不会对处于同一特权级别的应用程序起作用。这不会减少 UIPI 的使用吗？
作为系统管理员，您不应该这样做。如果我向您的应用程序发送窗口消息，我希望它能够正确处理它们，而不是决定我没有“经过身份验证”。 Windows 安全性是基于用户的，而不是基于应用程序的，因此即使尝试这样做也没有任何意义；毕竟，用户可以修改您流程中的代码，因此根据定义，他们可以绕过您可能采取的任何措施。
@asudhak 在这种情况下，请在处理事件时检查它是否仍然适用（或启用）。
按钮最初是如何被禁用的？大概你有一个函数或一些内部状态来回答“应该立即启用按钮吗？”这个问题。在处理 BM_CLICK 时调用相同的函数等，如果当时不应该启用按钮，则忽略该消息。

【解决方案1】：

如果应用程序在用户自己的上下文中运行，那么它只能做用户可以做的事情。经常被忽视的推论是，应用程序可以做的任何事情，用户都可以做。

因此，不必过多担心此类应用程序上的按钮是否“真正”禁用。无论如何，用户总能找到另一种方法来执行按钮将要执行的任何操作。（这可能是通过使用注册表编辑器，获取具有相同功能的另一个应用程序，或者，如果没有其他方便，他们可以在调试器中运行应用程序并强制它重新启用按钮。）

适当的解决方案取决于上下文：

在许多情况下，最合适的解决方案是停止担心它。您应该能够信任您的用户，如果不能，那是 HR 问题，而不是技术问题。
如果您是一名系统管理员，您试图锁定一台 kiosk 机器（该机器将由不受信任的用户使用，通常使用某种类型的单个访客帐户），那么您可以使用 AppLocker 或软件限制定义允许用户运行哪些应用程序的策略。由于 Enabler 和 TurnItOn 不会出现在您的列表中，因此用户将无法运行它们来绕过您的安全策略。

【讨论】：