Add option to redact sensitive information from public facing error messages

[HamzaOralK]

Hi people,

We are using Graylog in our internal applications also when we aggregate or container logs. Recently we had a pentest and they came up with the exact issue that the internal server errors are giving too much information.

For example if you go to our logging service like https//logging.example.com/%%2e, it throws an error like the following,

java.lang.IllegalArgumentException: java.net.URISyntaxException: Malformed escape pair at index 28: https//logging.example.com/%.
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.getRequestUri(GrizzlyHttpContainer.java:463)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:339)
	at org.glassfish.grizzly.http.server.HttpHandler$1.run(HttpHandler.java:200)
	at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:180)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.URISyntaxException: Malformed escape pair at index 28: https//logging.example.com/%.
	at java.net.URI$Parser.fail(URI.java:2848)
	at java.net.URI$Parser.scanEscape(URI.java:2978)
	at java.net.URI$Parser.scan(URI.java:3001)
	at java.net.URI$Parser.checkChars(URI.java:3019)
	at java.net.URI$Parser.parseHierarchical(URI.java:3105)
	at java.net.URI$Parser.parse(URI.java:3053)
	at java.net.URI.<init>(URI.java:588)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.getRequestUri(GrizzlyHttpContainer.java:461)
	... 6 more

There were a discussion in this link from 2018 but there were no concrete solutions. Is there a way to solve this kind of a problem?

[kroepke]

Hi!

I don't think there's currently a way to influence what is displayed there.
The balance here is that for certain users it's important to see what the actual error was, but for public-facing instances, I can see the reluctance to display anything beyond "Error".

As much as I dislike global switches, I'm equally reluctant to remove all information from the error messages because that makes it extremely difficult to debug issues.
Would a global "Suppress error information" checkbox solve your problem here?

(If so, I'd probably move this into the server repository for a fix later)

Thanks!

[HamzaOralK]

Maybe some sort of default error page would be awesome, else a checkbox to suppress error information is also a cool solution.

[kroepke]

Thanks! I'll bring it up with some folks to see what we can do here.

[0xtaf]

Hi @kroepke! Is there any progress with it?