最近一篇关于Java反序列化攻击的Foxglove Security文章，链接到针对主要应用程序服务器以及Spring和Groovy应用程序的示例代码，引起了很多恐慌。这篇文章指出，这些漏洞利用绕过了身份验证，因为在进行身份验证检查之前对对象负载进行了反序列化。不过，它并没有具体命名或讨论Spring HttpInvoker，我在其他地方也找不到关于这一点的明确声明。
对于通过Spring HttpInvoker公开的远程服务，使用带有基本身份验证的Spring Security，是否会在反序列化（潜在的恶意）对象负载之前执行身份验证检查？或者，文章中关于"身份验证不会保护您免受此攻击"的断言也适用于HttpInvoker服务吗？
我决定自己测试一下。为了测试处理入站HTTP Invoker服务调用时的事件序列，我设置了一个简单的Spring Boot入门应用程序，如下所示：
- 一个HelloWorld服务公开了一个简单的hello（）方法，该方法将自定义HelloDto对象作为输入参数
- 在HelloDto中自定义序列化逻辑，以记录序列化和反序列化
- Spring Security用于保护服务的基本身份验证
我将Spring Security和Spring Remoting的日志记录提升到Debug级别，然后通过一个简单的JUnit测试客户端远程调用HelloWorldService。我通过控制台日志确认，在反序列化发生之前，Spring Security正在对调用者进行身份验证和授权。
当我仔细思考一系列事件时，这是有道理的。Spring Security是作为一个过滤器链来实现的，而HTTP Invoker逻辑是由DispatcherServlet来处理的，该Servlet将在过滤器提前执行后从逻辑上获得控制。
如果Spring的任何一位大师都能确认这是一个准确的解释（或者特别是如果有任何模糊的"边缘情况"，在调用方经过身份验证之前，反序列化仍然会影响我们），我们将不胜感激。
我会在谷歌上搜索ysosserial有效负载生成器。使用每个选项创建有效负载，然后使用正确的内容类型集将其卷曲到端点。我们在工作中做到了这一点，并对我们可以在开发服务器上远程执行代码感到惊讶。