Are server 500 errors a security issue?

Question

I've found that it's possible to cause 500 errors on a server using curl and a faked GWT-Permutation with a POST payload. The payload is generating a java.lang.Exception on an Apache server.

Does this open up a security issue? Should I report it to Google's GWT support?

To clarify the question: Would a significant number of server errors be a concern as a denial of service. I.e. could they exhaust server resources. (Sorry, if this is too hypothetical).

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)

Thanks! Dave

Answer 1

There are two security issues which come to mind.

1) Leaking information about your system. If a stack trace makes it back to the client side, then you can end up leaking information which could help an attacker build a more effective attack. You've mentioned that this stack trace is only in your logs, so this point is not an issue.

2) Denial of service. This is an issue if an attack causes you to leak resources or if it makes the server side do far more processing per request than must be done on the client side.

In your case, if this particular exception causes a connection to be leaked (ie. not properly closed), then you have a DoS attack. If this attack causes your server to do heavy processing, you also have a DoS attack. However it looks like neither is probably the case. It looks like a NumberFormatException just kills the request while the server is parsing it. This is probably less expensive computationally than responding to a well formed request.

From the perspective of adhering to the HTTP spec, there exists a decent argument that the server should return a HTTP 400 Bad Request instead of a HTTP 500 Internal Server Error since the error was the result of a malformed request parameter, however that does stretch into the realm of the pedantic.