SPARK-5983 [WEBUI] Don't respond to HTTP TRACE in HTTP-based UIs

[srowen]

Disallow TRACE HTTP method in servlets

[SparkQA]

Test build #27949 has started for PR 4765 at commit 421b25b.

• This patch merges cleanly.

[SparkQA]

Test build #27949 has finished for PR 4765 at commit 421b25b.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[AmplabJenkins]

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/27949/
Test PASSed.

[srowen]

@kayousterhout can I get your second opinion on this? I know you've worked on a lot of the UI code.
It's a tiny bit of extra code for a quite theoretical low-priority security issue, but one that was reported by a customer's pen testing tool.

[vanzin]

Looks ok, but rather verbose (and new servlets might forget it)... wonder if there's an easy way to disable it in the org.eclipse.jetty.server.Server instance itself.

[srowen]

Yeah I picked at this for a while, but didn't see a way. It's not really a server-level, or HTTP connector-level issue, but a web-app-level policy issue. I found a way to specify security constraints positively (e.g. list the methods you want to support) but it would require refactoring the code to use the one createServlet method, and the two instances that don't use it seem to do so because they can't fit neatly into the same paradigm. Basically everything else looked uglier.

I'd still like to keep this open for a while in case anyone knows of a simple way to do this in Jetty.

[srowen]

Going once going twice... I'd love to hear a slightly tidier way to handle this across the board, although, the code is just 3 lines duplicated in 3 clear places, so not a great mess nor one that couldn't be refactored later if someone had a bright-er idea.