服务器500错误是安全问题吗？

Question

我发现，使用curl和带有POST有效负载的假GWT排列可能会在服务器上造成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)

谢谢!戴夫

Answer 1

很明显，堆栈跟踪就是信息公开。

除此之外，我认为用户应该--永远不会--看到500系列错误，因为用户应该做些什么呢？

此外，从赋值和补救的角度来看，500错误可能意味着存在任何数量的漏洞，或者根本不存在漏洞。我们怎么知道？

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

海事组织所有小组都需要处理所有例外，没有借口。

Answer 2

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

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

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

在您的情况下，如果此特殊异常导致连接泄漏(即。如果没有正确关闭)，则会发生DoS攻击。如果此攻击导致服务器执行大量处理，则还会发生DoS攻击。然而，看起来两种情况都不可能是这样的。看起来，当服务器解析请求时，NumberFormatException就会杀死它。在计算上，这可能比响应格式良好的请求花费更少。

从遵守HTTP规范的角度来看，有一个不错的论点，即服务器应该返回一个HTTP 400坏请求，而不是HTTP 500内部服务器错误，因为该错误是格式错误的请求参数造成的，但是这确实延伸到了迂腐的领域。