Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Burp Enterprise 500 Error with Logstash http_poller Plugin

Timmins, | Last updated: Feb 27, 2019 12:28PM UTC

Hi, Since I was thinking the Burp Enterprise API could be easily ingestible from Logstash I'm attempting to use HTTP_Poller plugin to ingest scan results into Elasticsearch. My script is basically what's recommended from the official documentation and works when I ingest cluster health from Elasticsearch. My ELK stack and Burp Enterprise server is located on same the box. Below is my HTTP Poller script. http_poller { type => "http_poller" urls => { burp_enterprise => { url => "http://localhost:8085/api/myapikey/v0.1/scan/10" method => get headers => { Accept => "application/json" } } } request_timeout => 60 schedule => {"cron" => "*/1 * * * *"} codec => "json" metadata_target => "http_poller_metadata" } And the full error I'm getting from Burp Enterprise is the below: <title>Error 500 Server Error</title> </head> <body><h2>HTTP ERROR 500</h2> <p>Problem accessing /api/myapikey/v0.1/scan/10. Reason: <pre> Server Error</pre></p><h3>Caused by:</h3><pre>java.io.IOException: Sent data size does not match expected at net.portswigger.enterprise.web.rest.e.b.b(Unknown Source) at net.portswigger.enterprise.web.rest.e.b.doGet(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) at org.eclipse.jetty.websocket.servlet.WebSocketServlet.service(WebSocketServlet.java:177) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:867) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1623) at net.portswigger.enterprise.common.e.e.doFilter(Unknown Source) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) at org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:61) at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:753) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.Server.handle(Server.java:502) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) at java.base/java.lang.Thread.run(Thread.java:844) </pre> Any ideas why Burp Enterprise is responding in this way? I can query this particular scan result with no issues from any other client.

Burp User | Last updated: Feb 27, 2019 04:21PM UTC

I tested this by using Burp's Suite API and had no issues, so this is definitely just the Enterprise version.

PortSwigger Agent | Last updated: Mar 04, 2019 01:48PM UTC

Hi Adam, Thanks for raising this. It does seem that this is a bug, I've raised a ticket to get it fixed.

Liam, PortSwigger Agent | Last updated: Mar 04, 2019 04:11PM UTC