If you want to lock down a java-based webapp server, jetty, tomcat,
fuseki whatever, then another starting point is to put it behind a
reverse proxy (httpd, nginx etc), slave the java server to only receive
request from localhost i.e. the reverse proxy.
httpd, nginx have a much greater range of facilities to defend the service.
On 28/01/16 11:36, Massimiliano Ricci wrote:
Dear All,
for a customer we'd like to use Fuseki 2.3.1. on Linux RedHat as a
standalone server.
Unfortunatelly we've encountered an anomaly of "Information Exposure"
(CWE-200 - http://cwe.mitre.org/data/definitions/200.html), in particular
the Fuseki and JETTY versions are showed. For example, if I submit an
incorrect query, it's shown:
Error 400: ...
Fuseki - version 2.3.1 ....
And in response header:
HTTP/1.1 200 OK
Date: Thu, 28 Jan 2016 10:20:34 GMT
Cache-Control: must-revalidate,no-cache,no-store
Pragma: no-cache
Content-Type: text/plain;charset=utf-8
Content-Length: 31
Server: Jetty(9.3.z-SNAPSHOT)
CWE-200 is about private or useful information to an attacker.
Counting version numbers as sensitive or attack information is debatable
IMO. At most, it is minor - it's all in the POM files and source code
for open source - and attacking an unknown version is a matter of
running an attack on all possible versions in parallel.
Even the Apache webserver at www.apache.org puts in the version:
Server: Apache/2.4.7 (Ubuntu)
Why it says "9.3.z-SNAPSHOT" I don't know - this is a known Jetty issue
- the version of Jetty is not a snapshot and it was pulled from maven
central. Weirdly, current development, same Jetty, prints 9.3.3.v20150827.
The Apache Jena release process will not proceed if a SNAPSHOT is found,
not that maven central has snapshots at all.
In order to don't show the Jetty version I've modified the
"jena-3.0.1-source-release\jena-3.0.1\jena-fuseki2\examples\fuseki-jetty-https.xml":
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "
http://www.eclipse.org/jetty/configure_9_3.dtd";>
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<New id="httpConfig" class="org.eclipse.jetty.server.HttpConfiguration">
<Set name="sendServerVersion"><Property
name="jetty.httpConfig.sendServerVersion"
deprecated="jetty.send.server.version" default="false" /></Set>
</New>
</Configure>
but running fuseki:
java -Xmx16384M -jar fuseki-server.jar --jetty-config=fuseki-jetty.xml
--port=8080 --loc=/mytdb /myDataSet
the following exception was raised:
10:36:11 INFO Server :: Jetty server config file =
/space/weblogic/apache-jena-fuseki-2.3.1/fuseki-jetty.xml
10:36:11 ERROR Server :: SPARQLServer: Failed to configure
server: 0
java.lang.ArrayIndexOutOfBoundsException: 0
That means the jetty configuration file has not defined a connector.
If that was the whole file fuseki-jetty.xml then it's incomplete. The
connector is created by <Call name="addConnector"> in the example.
There are examples at:
http://www.eclipse.org/jetty/documentation/current/configuring-connectors.html#jetty-connectors
I used fuseki-jetty-https.xml with only the setting for
name="sendServerVersion" changed and it worked (no Server line for Jetty)
at
org.apache.jena.fuseki.jetty.JettyFuseki.configServer(JettyFuseki.java:266)
at
org.apache.jena.fuseki.jetty.JettyFuseki.buildServerWebapp(JettyFuseki.java:222)
at
org.apache.jena.fuseki.jetty.JettyFuseki.<init>(JettyFuseki.java:91)
at
org.apache.jena.fuseki.jetty.JettyFuseki.initializeServer(JettyFuseki.java:86)
at
org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.exec(FusekiCmd.java:358)
at jena.cmd.CmdMain.mainMethod(CmdMain.java:93)
at jena.cmd.CmdMain.mainRun(CmdMain.java:58)
at jena.cmd.CmdMain.mainRun(CmdMain.java:45)
at
org.apache.jena.fuseki.cmd.FusekiCmd$FusekiCmdInner.innerMain(FusekiCmd.java:95)
at org.apache.jena.fuseki.cmd.FusekiCmd.main(FusekiCmd.java:60)
I think because Fuseki is using the wrong version Jetty (9.3.z-SNAPSHOT
instead 9.3.3).
Fuseki at the 2.3.1 release is running with 9.3.3.v20150827
See
https://github.com/apache/jena/blob/jena-3.0.1/jena-fuseki2/pom.xml
For Fuseki version I didn't find any solution.
Could anyone suggest us how to figure out this issue?
There are proprerties to set to avoid it?
Do I have to open an issue on JIRA?
Thanks,
Max
Andy
