My team had a pentest done, and they managed to ge...

# http4k

[Andrew O'Hara]

My team had a pentest done, and they managed to get a Jetty stacktrace in a response by using an invalid URL. They see this is a vulnerability, even though my actual application guards against leaking stacktraces. Is this something that http4k's server wrapper should be guarding against? Or should I just ignore the result? Because all it says is that the server is using Jetty, which is already advertised in the Jetty response headers.

[dave]

where did the stacktrace originate?

[dave]

We generally use a CatchAll filter to catch any unhandled exceptions that originate inside the http4k layers

[dave]

Generally the app writer is responsible for decorating their http handlers

[dave]

just out of interest - what was the URL?

[dave]

it's better to never return a stack to a public call TBH

[Andrew O'Hara]

It seems to have been caused by a //. The stacktrace was from Jetty itself. Never hit my application. Not sure if this is Jetty's fault, or if there was something the http4k wrapper for Jetty could have configured to avoid it.

[dave]

can you see http4k anywhere in the stack?

[dave]

if you can then there's something we can do about it

[Andrew O'Hara]

Ok so I just reproduced it myself and got this. Http4k isn't in the stacktrace, but http4k is the one that configures the jetty server during init. I figure if there's a way we can compensate for it, it would be there.

org.eclipse.jetty.http.BadMessageException: 400: Ambiguous URI empty segment
	at org.eclipse.jetty.server.internal.HttpConnection$HttpStreamOverHTTP1.headerComplete(HttpConnection.java:1189)
	at org.eclipse.jetty.server.internal.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:959)
	at org.eclipse.jetty.http.HttpParser.parseFields(HttpParser.java:1251)
	at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1543)
	at org.eclipse.jetty.server.internal.HttpConnection.parseRequestBuffer(HttpConnection.java:580)
	at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:404)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99)
	at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:478)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:441)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293)
	at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201)
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:410)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:971)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1201)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1156)
	at java.base/java.lang.Thread.run(Unknown Source)

[dave]

well regardless - I think this should be a jetty thing - they shouldn't be leaking a stacktrace.. maybe open an issue in jetty?

[Andrew O'Hara]

Yeah, probably Jetty's responsibility 🤷 . I'll see about posting an issue.

[dave]

@Andrew O'Hara I wrote a quick test in the server contract... looks like just Jetty 12 affected

[dave]

TFFT 😉

[Andrew O'Hara]

Not sure what TFFT means 😛

[dave]

Thank Flip For Tests!

[Andrew O'Hara]

I see even the latest Jetty 12 version exhibits the issue too

[dave]

or something equivalent..

[Andrew O'Hara]

Jetty will probably want a way to reproduce the issue with pure Jetty, so I'll see about that later. Thanks for confirming it's only Jetty 12

[dave]

The test I wrote was just in the ServerContract

@Test
    fun `illegal url`() {
        assertThat(client(Request(GET, "$baseUrl/v1/foo//bar")).bodyString().lowercase(), !containsSubstring("exception"))
    }

[Andrew O'Hara]

What does Jetty 11 return?

[dave]

<h1>Bad Message 400</h1><pre>reason: Ambiguous URI empty segment</pre>

[Andrew O'Hara]

Yeah, that's better

[Andrew O'Hara]

Security report away!

[andyg]

exposing the stacktrace appears to be a long-running issue: https://stackoverflow.com/questions/62331132/disable-the-default-stacktrace-error-response-in-jetty

you could of course create a custom error page, or use your reverse proxy to sanitize/reject similar URLs

[Andrew O'Hara]

So after talking to the Jetty security team about it. They don't see this as a security issue, and point out that you can even disable stacktraces by configuring the default error handler. So http4k could override this if it wanted. However, they admit it might be more appropriate to make suppression the default action, and appear to be making a PR to change it.

[dave]

I'm hesitant to make the ServerConfigs more complicated than absolutely necessary. Let's see what they come back with.

[Andrew O'Hara]

They're changing the default in 12.0.8

[dave]

👍