Jetty hardening
February 7, 2015 Leave a comment
Hardening may be a bit of stretch here, so before you spent your time with the post, I’ll tell you what we’re going to do here:
- Disable directory browsing (definitely security hole) in the web application context.
- Disable default Jetty error messages – both in application context and out of it (if you’re not running application in the root context).
- And a little shutdown hook that helps your application lifecycle in case of unexpected process termination (covers break/ctrl+C, not kill -9 obviously :-)).
This all applies to Jetty 9.2.x, I’m pretty sure these things change slightly between major Jetty versions, so you may need to adjust it for versions 8 or 7.
This is a compilation of some research on the internet and actual Jetty debugging, applied to our Spring based web application run under Jetty (and wrapped with Launch4J) and if you know how to do things better I’ll gladly hear about it in comments of course. It is also loose continuation of our previous parts:
So, let’s see some code!
The result
Ok, maybe not the best story-telling, but let’s see the actual result here first. I left also lines with logging, we can argue about log levels, but that’s not the point here. Because it’s a longer listing with all the features from previous post, I highlighted the lines that are related to today’s post:
import java.io.IOException;
import java.nio.file.DirectoryStream;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.security.ProtectionDomain;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.eclipse.jetty.server.Request;
import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.servlet.ErrorPageErrorHandler;
import org.eclipse.jetty.webapp.WebAppContext;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
/**
* Port is customizable using -Dport=8181 - default is 8080.
* Application context is customizable using -Dcontext=xxx - default is "". Initial slash is
* always prepended internally after any leading or trailing slashes (/) are discarded from the provided value,
* so both -Dcontext= and -Dcontext=/ define root context.
*/
public class RestMain {
private static final Logger log = LoggerFactory.getLogger(RestMain.class);
public static void main(String[] args) throws Exception {
int port = Integer.parseInt(System.getProperty("port", "8080"));
String contextPath = System.getProperty("context", "");
log.debug("Going to start web server on port {} with context path {}", port, contextPath);
Server server = new Server(port);
WebAppContext context = new WebAppContext();
context.setServer(server);
context.setContextPath('/' + contextPath);
context.setInitParameter("org.eclipse.jetty.servlet.Default.dirAllowed", "false");
context.setErrorHandler(new ErrorHandler());
ProtectionDomain protectionDomain = RestMain.class.getProtectionDomain();
String warPath = protectionDomain.getCodeSource().getLocation().toExternalForm();
if (warPath.toLowerCase().endsWith(".exe")) {
warPath = prepareWarPathFromExe(warPath, "WEB-INF");
} // else we assume dir or jar/war
context.setWar(warPath);
server.setHandler(context);
log.debug("WebAppContext set for server with location {}", warPath);
// default error handler for resources out of "context" scope
server.addBean(new ErrorHandler());
server.start();
if (!context.isAvailable()) {
//noinspection ThrowableResultOfMethodCallIgnored
log.error("Application did NOT started properly: {}", context.getUnavailableException().toString());
server.stop();
} else if (context.getWebInf() == null) {
log.error("Application was NOT FOUND");
server.stop();
} else {
log.debug("Application READY");
addJettyShutdownHook(server);
}
server.join();
log.debug("Exiting application");
}
private static void addJettyShutdownHook(final Server server) {
Runtime.getRuntime().addShutdownHook(new Thread() {
@Override
public void run() {
try {
log.debug("Exiting application (shutdown hook)");
server.stop();
} catch (Exception e) {
log.warn("Exception during server stop in shutdown hook", e);
}
}
});
}
private static String prepareWarPathFromExe(String pathToExe, String... prefixes) throws IOException {
Path tmpWarDir = Files.createTempDirectory("restmod");
final String warPath = tmpWarDir.toString();
log.debug("Extracting WAR from EXE into {}, prefixes {}", warPath, prefixes);
WarExploder warExploder = new WarExploder(pathToExe, warPath);
warExploder.explode(prefixes);
Runtime.getRuntime().addShutdownHook(new Thread() {
@Override
public void run() {
try {
deleteRecursive(Paths.get(warPath));
log.debug("Temporary WAR directory deleted");
} catch (IOException e) {
log.warn("Problems with deleting temporary directory", e);
}
}
});
return warPath;
}
private static void deleteRecursive(Path dir) throws IOException {
if (Files.isDirectory(dir)) {
try (DirectoryStream<Path> directoryStream = Files.newDirectoryStream(dir)) {
for (Path path : directoryStream) {
deleteRecursive(path);
}
}
}
Files.delete(dir);
}
/**
* Dummy error handler that disables any error pages or jetty related messages and returns our
* ERROR status JSON with plain HTTP status instead. All original error messages (from our code) are preserved
* as they are not handled by this code.
*/
static class ErrorHandler extends ErrorPageErrorHandler {
@Override
public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws IOException {
response.getWriter()
.append("{\"status\":\"ERROR\",\"message\":\"HTTP ")
.append(String.valueOf(response.getStatus()))
.append("\"}");
}
}
}
Now we can walk through these parts.
Directory browsing
This was the easy part after we accidently found out it is allowed. Just add this line to your WebAppContext:
context.setInitParameter("org.eclipse.jetty.servlet.Default.dirAllowed", "false");
We are running REST-like API under some context path and if we comment out this line, Jetty will nicely allow us to browse the directory (WEB-INF included). This line ensures that HTTP 403 Forbidden will be returned instead. How this status is treated…
Error handling in your application
There are errors you can treat in your application – these are not problem. And then there are cases that somehow slip out, there is no reasonable way how to intercept them and server displays some ugly error for it, introducing itself to the user completely. If I run application on http://localhost:8080/xxx and I hit that URL, I get the following output:
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> <title>Error 404 Not Found</title> </head> <body><h2>HTTP ERROR 404</h2> <p>Problem accessing /finrisk/easd. Reason: <pre> Not Found</pre></p><hr><i><small>Powered by Jetty://</small></i><hr/> </body> </html>
That is not bad, but I’d like short JSON we use for error messages. This can be customized in web.xml:
<!-- somewhere at the end of web.xml → <error-page> <location>/api/0.1/error</location> </error-page>
This will point the application to our error resource and this is returned:
{"status":"ERROR","message":"HTTP 404"}
Alternatively we can achieve the same with custom Jetty ErrorHandler as we defined it at the end of our JettyMain class:
context.setErrorHandler(new ErrorHandler());
...
static class ErrorHandler extends ErrorPageErrorHandler {
@Override
public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws IOException {
response.getWriter()
.append("{\"status\":\"ERROR\",\"message\":\"HTTP ")
.append(String.valueOf(response.getStatus()))
.append("\"}");
}
}
This effectively replaces your web.xml definition (if present) and if you debug your application you can confirm that with a breakpoint that would be reached without this jetty line and will not be when it’s present.
How about URLs out of webapp context?
Let’s now access some URL out of our application – like http://localhost:8080/yy – this will result in very similar default Jetty error page like we’ve seen already:
<html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/> <title>Error 404 </title> </head> <body> <h2>HTTP ERROR: 404</h2> <p>Problem accessing /. Reason: <pre> Not Found</pre></p> <hr /><i><small>Powered by Jetty://</small></i> </body> </html>
This is also easy to fix, because we can reuse our ErrorHandler – just add this line for your Jetty Server instance:
server.addBean(new ErrorHandler());
But are we really done?
Not so fast…
The trouble is that error handler (or error resource configured in web.xml) is only used when Jetty (or any servlet container) thinks there was an error. If you handled the exception some other way, then this ErrorHandler is not used – whatever HTTP status you send.
We use Jersey as our REST API provider where you can register ExceptionMapper for particular exception type (and all its subtypes). When this is triggered and you populate javax.ws.rs.core.Response with the output and set HTTP status, it will not trigger this error page. We handled the error once, no reason to do it twice.
But in case of Jersey there are exception mappers for JSON parse errors and these may leak some information. Let’s try any URL that expects JSON in POST with unpaired curly brace and you’ll get this error (going around your custom ErrorHandler or error page):
Unexpected end-of-input: expected close marker for OBJECT (from [Source: org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream@1986598; line: 1, column: 0]) at [Source: org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream@1986598; line: 1, column: 3]
This is not acceptable, but in this case you have to fight the framework (Jersey) to unregister internal mappers and register yours to get back on track. But obviously, this is out of scope of this blog post. Just remember that we’re covering only unhandled errors and any other error/exception handlers has to be checked too.
Shutdown hook
Finally something straightforward and not Java EE at all. When your Jetty server starts and application (Java process) gets terminated somehow, it will not stop the Jetty server in a graceful manner. With it goes down our Spring application – and if you have components with @PreDestroy, these method will likely not get run.
To do better than this we utilize Java’s shutdown hooks. The code goes like this:
// after Jetty starts OK with our app running
addJettyShutdownHook(server);
...
private static void addJettyShutdownHook(final Server server) {
Runtime.getRuntime().addShutdownHook(new Thread() {
@Override
public void run() {
try {
log.debug("Exiting application (shutdown hook)");
server.stop();
} catch (Exception e) {
log.warn("Exception during server stop in shutdown hook", e);
}
}
});
}
All we have to do is call server.stop(). Would finally block in the main method do the same? Probably – I’m too tired to try… but mainly – shutdown hook communicates “I’ll be run when the process goes down” much better I think.
Finally
There’s a lot more to do with Jetty – and I don’t know most of it. I’m not doing any SSL here or Jetty based authentication, but aforementioned little patches should help it a lot. In case of error handler vs error page within the webapp context – it’s your choice probably. If you don’t have error page yet, then it is the easy one. But unless you run the application on the root context (/) you definitely want to shut up Jetty’s default messages in production. Finally – shutdown hook will help the webapp going down nicely. This is twice so important if you have another container inside (like Spring). In any case, it makes our applications graceful, right? Who doesn’t want to have graceful applications? :-)
Recent Comments