Windows Vista 中/高完整性级别进程之间的拖放

发布于 2024-07-29 02:40:45 字数 279 浏览 6 评论 0原文

在 Windows Vista 中，我无法将文件拖/放到应用程序的窗口中，因为它作为高完整性级别进程运行。我需要以较高的速度运行它，但我还需要能够接受从低/中完整性级别进程（如 Windows 资源管理器）中删除的文件。我相信是 UIPI 阻止了拖/放操作。我知道我可以使用 ChangeWindowMessageFilter 函数来允许某些 Windows 消息绕过 UIPI，但我不确定要添加哪些消息以允许拖/放操作。 ChangeWindowMessageFilter 是允许这种情况的正确方法，还是有更好的方法？谢谢！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

我为君王 2024-08-05 02:40:45

考虑此博客条目的标题：
“为什么不应使用 10 英尺的距离触摸 ChangeWindowMessageFilter杆...”，
我想这不是最好的方法；）

现在，乍一看这似乎是一个很好的方法 - 毕竟，只有当您确定可以完全验证收到的消息（即使它来自不受信任的消息）时，您才会使用 ChangeWindowMessageFilter来源，这样就不会出错，对吗？
问题是，即使您这样做，您也经常会无意中打开您的程序以进行攻击。
考虑一下自定义窗口消息通常是如何使用的；实际上，现有的所有常见控件在自定义类消息范围中都有“危险”消息（例如 WM_USER 和朋友）。
此外，许多程序和第三方库会混淆 WM_USER 和 WM_APP，因此您的程序可能会通过 WM_USER 和 WM_USER 进行跨进程通信WM_APP，通过用于做出敏感决策或包含指针参数的“危险”消息。

在这篇博客文章的评论中，讨论了另一种方法，但结论几乎相同：

我会使用RegisterWindowMessage，然后通过ChangeWindowMessageFilter允许。
但是，请注意，您不能设计传递指针或其他不受信任值的跨进程窗口消息接口，否则您将创建安全漏洞。
出于这个原因，我倾向于避免在大多数跨进程 IPC 的所有消息中使用 window at all 消息（如果可能的话），因为使用它们以安全的方式完成重要的事情通常非常困难。

注意：此条目“那么，今天谁想设计一个功能？”说明了同样的问题，并指出了 Raymond Chen 的富有洞察力的文章：

它们都详细说明了问题。
此 ServerFault 问题“

另请参阅此有关 IE 的文章

Considering the title of this blog entry:
"Why you shouldn’t touch ChangeWindowMessageFilter with a 10-ft pole…",
I guess it is not the best approach ;)

Now, this might seem like a great approach at first - after all, you’ll only use ChangeWindowMessageFilter when you’re sure you can completely validate a received message even if it is from an untrusted source, such that there’s no way something could go wrong, right?
Well, the problem is that even if you do this, you are often opening your program up to attack unintentionally.
Consider for a moment how custom window messages are typically used; virtually all the common controls in existence have “dangerous” messages in the custom class message range (e.g. WM_USER and friends).
Additionally, many programs and third party libraries confuse WM_USER and WM_APP, such that you may have programs communicating cross process via both WM_USER and WM_APP, via “dangerous” messages that are used to make sensitive decisions or include pointer parameters.

In the comments of this blog entry, an alternative approach was discussed, but with pretty much the same conclusion:

I would use RegisterWindowMessage and then allow that via ChangeWindowMessageFilter.
However, be aware that you cannot design a cross-process window message interface that passes pointers or other untrusted values or you are creating a security hole.
For this reason, I would tend to avoid using window at all messages for most cross-process IPC (if possible), as it is typically very difficult to do non-trivial things in a secure fashion using them.

Note: this entry "So, who wants to design a feature today?" illustrates the same problem, and points to the insightful articles of Raymond Chen:

which both detail the issue.
This ServerFault question "Why can’t I drag/drop a file for editing in notepad in Windows Server 2008?" also includes some answers, but no quick-win.