异步调用是否会引入安全漏洞

Question

只需阅读需求文档。

其中一个要求是不应该有任何异步调用。这似乎是一项安全要求。

问题是使用异步调用有哪些安全漏洞？或任何其他理由禁止他们？

所有传输均通过Https / SSL进行。这些呼叫是两个系统之间的Web服务。

Answer 1

异步调用没有任何本质上的错误，尽管它们可能更难以使用。

Answer 2

我唯一能想到的是可能是轻微的机会，“完成”事件可能被欺骗，从而将恶意数据提供给您的应用程序。

然而，我原本以为这种可能性很小。

Answer 3

异步调用，定义为进程中的一个线程，该进程在父线程继续其业务的同时产生另一个线程来进行调用并侦听结果，并不比同步调用的安全性更强或更低。从进程的外部观察者的角度来看，两者之间的唯一区别在于，副线程是在等待调用结果时被阻塞的线程，而不是主线程。新线程获取新的堆栈和执行指针，但与进程的所有其他线程共享堆，并且线程可以通过引用访问其他线程堆栈中的变量。它是相同的程序，在相同的内存空间中执行，它只是从两个地方而不是一个地方执行代码。

此外，可能无法编写没有任何异步操作的C＃程序;运行时内置了许多这样的操作。例如，垃圾收集和运行时用于与各种I / O层通信的线程。事件驱动的UI编程具有很强的线程;只要用户做某事，运行时的“UI线程”就会调用程序的“主线程”;否则它只是在等待。

Answer 4

异步调用通常会出现竞争条件，有时会导致安全漏洞。

但是，出于这个原因而完全禁止它们就像禁止使用有符号整数一样，因为它们有时 lead to security vulnerabilities - 解决方案是理解问题，不要把它扫到地毯下面。

Answer 5

使用异步调用很难保持正确的调用上下文，因为调用的最后部分通常会在随机线程上执行.Impersonation，运行时设置的线程本地对象（如ASP.Net中的HttpContext.Current），常规在运行可能依赖它们的代码之前，需要正确恢复静态/线程本地对象。

不允许异步调用可以保证问题 - 桌面应用程序中的无响应UI和服务应用程序的性能问题。

同样，其他人都指出编写异步代码比同步更难。有些库可以帮助编写这样的代码 - 即http://msdn.microsoft.com/en-us/magazine/cc546608.aspx