我发现使用curl和伪造的GWT-Permutation以及POST有效负载在服务器上造成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)
谢谢! 戴夫
答案 0 :(得分:2)
有两个安全问题浮现在脑海中。
1)泄漏有关系统的信息。如果堆栈跟踪使其返回到客户端,那么您最终可能会泄漏信息,这可能有助于攻击者构建更有效的攻击。您已经提到此堆栈跟踪仅在您的日志中,因此这一点不是问题。
2)拒绝服务。如果攻击导致您泄漏资源,或者它使服务器端对每个请求执行的处理远多于客户端必须执行的操作,则会出现此问题。
在您的情况下,如果此特定异常导致连接泄露(即未正确关闭),则您有DoS攻击。如果此攻击导致您的服务器执行繁重的处理,则您还会遭受DoS攻击。然而,看起来似乎都不是这样。看起来NumberFormatException
只是在服务器解析它时才会杀死请求。计算结果可能比响应格式良好的请求要便宜。
从遵守HTTP规范的角度来看,存在一个不错的论点,即服务器应该返回HTTP 400 Bad Request而不是HTTP 500 Internal Server Error,因为错误是格式错误的请求参数的结果,但是确实延伸到迂腐的领域。