CODEWITHSUNDEEP
javasecuritygwt
dfdumaresq
dfdumaresq

Reputation: 1637

Are server 500 errors a security issue?

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

Upvotes: 3

Views: 6928

Answers (2)

Michael
Michael

Reputation: 729

Obviously a stack trace is information disclosure.

Beyond that, I believe that a user should -never- see a 500 series error because - what is the user supposed to do about it?

Additionally, from a pentesting and remediation perspective - a 500 error could mean that any number of vulnerabilities exist, or none at all. How do we know?

It also makes it difficult to test the risk of a specific vulnerability. Using a recent example such as the now infamous Log4j vulnerabvility - if I send the ${jndi} payload and I get a 500 error - is it because the payload succeeded or is it entirely unrelated?

IMO all teams need to handle all exceptions, no excuses.

Upvotes: 1

Aurand
Aurand

Reputation: 5537

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.

Upvotes: 7

Related Questions