1

我发现使用 curl 和带有 POST 有效负载的伪造 GWT-Permutation 可能会在服务器上导致 500 错误。有效负载正在 Apache 服务器上生成 java.lang.Exception。

这会引发安全问题吗？我应该向 Google 的 GWT 支持报告吗？

为了澄清这个问题：大量的服务器错误是否会成为拒绝服务的问题。即他们可以耗尽服务器资源。（对不起，如果这太假设了）。

SEVERE: Exception while dispatching incoming RPC call
java.lang.NumberFormatException: Expected type 'int' but received a non-numerical value: 
    at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.getNumberFormatException(ServerSerializationStreamReader.java:999)
    at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.readInt(ServerSerializationStreamReader.java:537)
    at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.readString(ServerSerializationStreamReader.java:582)
    at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.prepareToRead(ServerSerializationStreamReader.java:488)
    at com.google.gwt.user.server.rpc.RPC.decodeRequest(RPC.java:240)
    at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:206)
    at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
    at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96)
    at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
    at java.lang.Thread.run(Thread.java:662)

谢谢！戴夫

4

2 回答 2

4

有两个安全问题浮现在脑海中。

1) 泄露有关您的系统的信息。如果堆栈跟踪返回到客户端，那么您最终可能会泄漏信息，这可能有助于攻击者构建更有效的攻击。您已经提到此堆栈跟踪仅在您的日志中，因此这一点不是问题。

2) 拒绝服务。如果攻击导致您泄漏资源，或者如果它使服务器端对每个请求进行的处理远远超过客户端必须完成的处理，那么这就是一个问题。

在您的情况下，如果此特定异常导致连接泄漏（即未正确关闭），那么您就有了 DoS 攻击。如果此攻击导致您的服务器执行繁重的处理，那么您也有 DoS 攻击。但是，看起来两者都不是。看起来好像NumberFormatException只是在服务器解析请求时终止了请求。这在计算上可能比响应格式良好的请求更便宜。

从遵守 HTTP 规范的角度来看，存在一个体面的论点，即服务器应该返回 HTTP 400 错误请求而不是 HTTP 500 内部服务器错误，因为错误是请求参数格式错误的结果，但这确实延伸到学究的境界。

于 2013-11-13T02:02:27.897 回答
0

显然，堆栈跟踪是信息泄露。

除此之外，我相信用户应该 - 永远 - 看到 500 系列错误，因为 - 用户应该怎么做？

此外，从渗透测试和修复的角度来看 - 500 错误可能意味着存在任意数量的漏洞，或者根本没有漏洞。我们怎么知道？

这也使得测试特定漏洞的风险变得困难。使用最近的示例，例如现在臭名昭著的 Log4j 漏洞——如果我发送 ${jndi} 有效负载并收到 500 错误——是因为有效负载成功还是完全不相关？

IMO 所有团队都需要处理所有例外情况，没有任何借口。

于 2022-02-16T15:28:57.283 回答