假設我有一個帶有按鈕的Windows GUI應用程序。我可以使用帶BM_CLICK的sendMessage winapi調用作爲調用的參數來模擬該按鈕上的點擊。防止跨進程SendMessage調用
現在，從安全角度來看，我不希望發生這種情況。即我的目標進程應該忽略來自另一個進程的sendMessage調用。有沒有規定可以做到這一點？一種驗證sendMessage調用的方法？
編輯：換句話說，我應該如何阻止Enabler，TurnitOn http://www.raymond.cc/blog/how-to-enable-and-access-disabled-grayed-out-buttons-windows-and-checkboxes/等應用程序訪問用戶不想訪問的功能？
如果應用程序在用戶自己的上下文中運行，那麼它只能執行用戶可以執行的操作。這個常常被忽視的必然結果是，應用程序可以做的任何事情，用戶都可以做到。
因此，對於這樣的應用程序上的按鈕是否「真正」被禁用或沒有擔心太多，沒有任何意義。無論如何，用戶總是可以找到另一種方法來完成按鈕的任何操作。 （這可能是通過使用註冊表編輯器，獲得具有相同功能的另一個應用程序，或者如果沒有其他方便的話，他們可以在調試器中運行該應用程序並強制它重新啓用該按鈕。）
適當的解決方案取決於上下文：
在許多情況下，最合適的解決方案是不要再擔心它。你應該能夠信任你的用戶，如果你不能，那就是人力資源問題，而不是技術問題。
如果應用程序正在爲更高級的環境（例如防病毒軟件的前端）提供接口，那麼安全決策（是否允許用戶執行此操作？）應該發生在後端。也就是說，安全決策需要由不在用戶控制範圍內的代碼來完成。
如果您是試圖鎖定自助服務終端機的系統管理員 - 一臺不受信任的用戶使用的機器（通常使用某種類型的單個來賓帳戶） - 則使用AppLocker或軟件限制策略定義允許用戶運行哪些應用程序。由於Enabler和TurnItOn不在您的列表中，用戶將無法運行它們來繞過您的安全策略。
這就是爲什麼有UIPI來阻止較低特權的應用程序向較高特權的應用程序發送消息。 （http://msdn.microsoft.com/en-us/library/bb625963.aspx）但是，不，你通常無法知道消息來自何處。畢竟，一些消息來自系統。 – jamesdlin 2012-08-06 19:34:32
謝謝！ UIPI是我不熟悉的東西。但根據該文件，UIPI不會針對處於相同特權級別的應用程序採取行動。這不會減少UIPI的使用嗎？ – asudhak 2012-08-06 19:54:29
作爲系統管理員說話，你不應該這樣做。如果我向你的應用程序發送窗口消息，我希望它能夠正確處理它們，而不是認爲我沒有被「認證」。 Windows安全性是基於用戶的，而不是基於應用程序的，所以即使嘗試這樣做也沒有意義。畢竟，用戶可以修改您的流程中的代碼，因此根據定義，他們可以繞過您可能採取的任何措施。 – 2012-08-06 20:14:54