Android 任务的“亲和力”似乎真的很难处理。该StrandHogg漏洞使用与“亲和力”的技巧来表现自己的另一个应用程序内。
到目前为止，我发现的信息并未提供漏洞的确切细节，但据我所知，这不是技术漏洞，而是设计不佳的 API，它允许巧妙的社会工程攻击。
StrandHogg 使用的 API 行为是否存在真实用例？
如果我理解正确的话，漏洞使用的 API 允许攻击者将自己的 Activity 放置在受害者的“Back stack”上。通过阅读 API 描述和提供的示例案例，此 API 的主要意图是允许来自其他应用程序的嵌入式活动显示在您自己的任务中。然而，StrandHogg 漏洞似乎与此相反：使用 API 将您自己的活动推送到另一个任务的“后退堆栈”上。
我最好的猜测是，该攻击使用了2011 年称为“操纵 Android 任务和回栈”的演示文稿第 100 页中描述的怪异行为。但是，我无法想象所描述行为的任何合理用例。
这不仅仅是受害者的“回栈”。有各种可能性。例如，假设受害者应用程序尚未启动。攻击者可以将他们的活动置于后台。然后，当用户点击受害者应用程序的图标启动它时，攻击者活动潜伏的“后台堆栈”可能会出现在前台并被视为受害者的“后台堆栈”，因为它声明了任务亲和力。
通过阅读 API 描述和提供的示例案例，此 API 的主要意图是允许来自其他应用程序的嵌入式活动显示在您自己的任务中。然而，StrandHogg 漏洞似乎与此相反：使用 API 将您自己的活动推送到另一个任务的“后退堆栈”上。
关于这个用例，可以这样想：活动 A 是预期的嵌入式活动，来自应用程序 1。应用程序 2 是想要合并活动 A 的活动。使用 StrandHogg 功能，应用程序 1 可以将活动 A 启动到应用程序中2 的后栈，从而允许用户将活动 A 体验为应用程序 2 中的嵌入式活动，即使它来自另一个应用程序。可以想象，一个合法的用例会让应用程序 2 首先与应用程序 1 通信以请求嵌入活动 A，然后应用程序 1 使用 StrandHogg 功能来执行此操作。
我们可以争辩说，这是正确的，这不是支持这种嵌入的最佳方式，因为它可能被滥用于网络钓鱼攻击和其他攻击，但这是另一个问题。
