stevel 2003/01/07 22:43:00
Modified: java/docs reference.html index.html
Added: java/docs security.html
Log:
new security document; more to the configuration reference.
Revision Changes Path
1.18 +15 -3 xml-axis/java/docs/reference.html
Index: reference.html
===================================================================
RCS file: /home/cvs/xml-axis/java/docs/reference.html,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- reference.html 3 Jan 2003 08:22:56 -0000 1.17
+++ reference.html 8 Jan 2003 06:43:00 -0000 1.18
@@ -614,9 +614,17 @@
</td>
</tr>
+<tr><td><b>axis.enableListQuery</b></td>
+<td>Flag to enable the "list services" feature. Set to true by default
+</td>
+</tr>
+
+
+<tr><td><b>axis.development.system</b></td>
+<td>Flag to switch the system from <i>production</i> (false) to
+<i>development</i> (true). A development system gives out stack traces
+and other information that production boxes should not.
-<tr><td><b></b></td>
-<td>
</td>
</tr>
@@ -645,7 +653,11 @@
<tr><td><b>wsdlFile</b></td>
<td>The path to a WSDL File; can be an absolute path or
a resource that axis.jar can load. Useful to export
-your custom WSDL file.
+your custom WSDL file. When specify a path to a resource, place a forward
+slash to start at the beginning of the classpath (e.g
+"/org/someone/res/mywsdl.wsdl"). How does Axis know whether to return
+a file or resource? It looks for a file first, if that is missing a
+resource is returned.
</td>
</tr>
1.12 +2 -0 xml-axis/java/docs/index.html
Index: index.html
===================================================================
RCS file: /home/cvs/xml-axis/java/docs/index.html,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- index.html 17 Dec 2002 01:15:50 -0000 1.11
+++ index.html 8 Jan 2003 06:43:00 -0000 1.12
@@ -27,6 +27,8 @@
<li>
<a href="user-guide.html">User's Guide</a></li>
+<li>
+<a href="security.html">Securing an Axis-based Web Service</a></li>
<li>
<a href="ant/ant.html">Axis Ant Tasks</a></li>
1.1 xml-axis/java/docs/security.html
Index: security.html
===================================================================
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Web Service Security</title>
<link href="axis.css" rel=stylesheet type=text/css>
<!--
authors:
Steve Loughran
-->
</head>
<body>
<center>
<h1>
<img SRC="images/axis.jpg" height=96 width=176></h1></center>
<h1>Web Service Security</h1>
<h2>The challenge of server security</h2>
A standard attack on a web site is usually that of identifying and
abusing badly written CGI scripts. Anything that gives read access to
the file system is a security hole, letting people get at the code
behind the site, often including database passwords and other sensitive
data, plus of course there are the core parts of the underlying
platform, which may contain important information: passwords, credit
card lists, user-private information, and the like. Unauthorized access
to this data can be embarrasing and expensive.
<p>
Having write access to the system leads to even greater abuses; defaced
web sites may be created, spoof endpoints written to capture caller's
data, or the database directly manipulated.
<h2>Is SOAP fundamentally insecure?</h2>
Some people, such as <a
href="http://www.counterpane.com/crypto-gram-0006.html";>
Bruce Schneier<a>, have claimed that SOAP is a
security disaster in the making, because of its ability to punch
through firewalls. However, because in SOAP over HTTP the client can
only make SOAP calls, not receive them, SOAP is no more insecure than
any other application which POSTs XML files to a web server. The clients
are safe unless the server (or its DNS address) have been subverted; the
server is vulnerable, and does need to be secured.
<h2>Common Attack Types</h2>
<ul>
<li>Denial of Service to a server
<li>Interception and manipulation of messages
<li>Forged client requests
<li>Forged server responses
<li>attempts to read the server file system/database
<li>Attempts to write to the server file system/database
</ul>
The most significant security risk comes from the fact that you are
writing code to provide functionality to calling programs. If that
functionality is offered to the wrong people, or if the code you wrote
creates a security hole, "unexpected functionality", then you have a
problem.
<h3>Special XML attacks</h3>
XML messages have a few intrinsic weakness, that Web Service creators
should know about. None of these problems are unique to SOAP; anyone
processing incoming XML needs to know and resist these.
<ol>
<li>The 'billion laughs' attack. Have a client post an XML doc of
extreme length/depth
<tt><ha><ha><ha>....</ha></ha></ha></tt>.
This does bad things to DOM parsers and memory consumption on the
server: a DoS attack.
<li>entity expansion attacks. If an XML doc header declares some
recursive entity declarations, and the file refers to them, then bad
things happen. Axis became immune to this between versions 1.0 and 1.1.
<li>Entities referring to the filesystem. <br>
Here you declare an entity referring to a local file, then expand it.
Result: you may be able to probe for files, perhaps even get a copy of
it in the error response. As Axis does not support entities any more, it
resists this. If your code has any way of resolving URLs from incoming
messages, you may recreate this problem.
</ol>
The other thing to know about XML is that string matching is not
enough to be sure that the content is safe, because of the many ways to
reformat the XML.
<h2>Authenticating the caller</h2>
The new Web Service security proposals offer to authenticate your
callers to your end point, and vice-versa. Axis does not yet implement
these, but we do support XML signatures via
<a href="http://xml.apache.org/security/index.html";>
a sister project.</a>
<p>
The other approach is to validate at the transport level, using HTTPS.
Configuring your web server to support https is definitely beyond the
scope of Axis documentation: consult your server docs. To support https
in the Axis client, you need to ensure the client has https support in
the runtime. This is automatic for Java1.4+; older versions need to add
JSSE support through Sun or an alternate provider.
<p>
Once you have HTTPS working at both ends you need to have the client
trust the server certificate -usually automatic for those signed by central
certification authorities, a manual process for home rolled
certificates.
<p>
Clients can authenticate themselves with client certificates, or HTTP
basic authentication. The latter is too weak to be trustable on a
non-encrypted channel, but works over HTTPS. The <tt>MessageContext</tt>
class will be configured with the username and password of the sender
when SOAP messages are posted to the endpoint; use the appropriate
getters to see these values. Note that Axis does not <i>yet</i>
integrate with the servlet API authentication stuff. Although the forms
authentication is literally off-axis when it comes to SOAP calls, the
UserPrincipal notion and integration with server configuration gives
some incentive for integration. (this is a hint to developers out there)
<h2> Automate Security Tests</h2>
If you find a security problem, write a test for it, such as a JUnit or
HttpUnit test, so that you can regression test the application and
installations for the problem. This is particularly important where it
is a configuration problem that creates the hole; it is almost
inevitable the same problem will re-occur on future installations.
<h2>Securing your Services</h2>
One of the key security holes in any Web Service is the code you write
yourself. It wont have as many eyes examining it as the Axis source
gets, deadlines get in the way of rigorous testing, and a complex web
service will bind to the valued items: private data, databases, other
servers, etc, that you want to defend against.
<p>
The key to this is not to trust the caller: their identity, their IP
address and most of all, their data. Here are some attacks to consider.
<h3>XML attacks</h3>
We listed these attacks earlier. If your service takes XML from an
attachment, or in a base-64 encoded string, parsing it as a standalone
document, then you are exposed to all these attacks. Also watch out for
standard XML syntaxes that integrate xlink or other ways of describing
URLs to fetch -such as SVG. You need to ensure the renderer only fetches
approved URLs.
<h3>Session Theft</h3>
Axis uses a good random number generator to generate session IDs, but
someone listening to an unencrypted conversation could hijack a session
and send in new messages. Recording sender info, such as the originating
IP address helps, though beware of proxied systems (e.g. AOL) that may
change the apparent origin of calls mid-session.
<h3>DOS attacks via load-intensive operations</h3>
Any request that takes time to process is a DOS attack target, as it
ties up the CPUs. Authenticate before long requests, and consider
watchdog threads to track really long execution times. If any bug causes
a request to spin forever.
<h2>Securing Axis</h2>
A core philosophy is 'defend in depth', with monitoring for trouble.
<h3>Disguise</h3>
One tactic here is to hide the fact that you are running Axis...look at
all the headers that we send back to describe the service, and if any
identify Axis, edit that constant in the source
<h3>Cut down the build</h3>
Rebuild Axis without bits of it you dont need. This is a very paranoid
solution, but keeps the number of potential attack points down. One area
to consider is the 'instant SOAP service' feature of JWS pages. They,
along with JSP pages, provide anyone who can get text files onto the web
application with the ability to run arbitrary Java code.
<h3>Rename things</h3>
The AxisServlet, the AdminService, even happyaxis.jsp are all in well
known locations under the webapp, which is called 'axis' by default.
Rename all of these, by editing web.xml for the servlet,
server-config.wsdd for the AdminService; the others are just JSP and WAR
files you can rename. You may not need the AdminService once you have
generated the server config on a development machine.
<h3>Stop AxisServlet listing services</h3>
To do this, set the Axis global configuration property
<tt>axis.enableListQuery</tt> to false.
<h3>Keep stack traces out of the responses </h3>
By default, Axis ships in <i>production</i> mode; if you set
<tt>axis.development.system</tt> to true in the configuration, stack
traces get sent over the wire in faults. This exposes internal
information about the implementation that may be used in finding
weaknesses.
<h3>Stop autogenerating WSDL</h3>
Trusted partners can still be given a WSDL file through email, or other
means; there is no need to return the WSDL on a production server. How
do you stop Axis returning WSDL? Edit the .wsdd configuration file, as
described in the <a
href="reference.html#individual_service">reference</a>, to return a
WSDL resource which is simply an empty <wsdl/> tag.
<h3>Servlets2.3: use filters for extra authentication</h3>
Servlets 2.3 lets you use filters to look at all incoming requests and
filter them however you like -including validating IP address, caller
credentials, etc. Caller address validation is useful for securing admin
services and pages, even when other endpoints are public. Of course,
router configuration is useful there too.
<h3>Log things</h3>
Although full logs are a DoS attack tactic in themselves, logging who
sends messages is often useful, for auditing and keeping track of what
is going on. Add more log4j tags to whatever bit of Axis appeals to you
to do this.
<h3>Run Axis with reduced Java rights</h3>
Java has a powerful and complex security system. Use it to configure
Axis with reduced rights. Axis tries to write to
WEB-INF/server-config.wsdd when updating the server config; and
somewhere else (its configurable) when saving compiled .jws pages.
<h3>Run the web server with reduced rights</h3>
On Unix this is pretty much a given, but even on Windows NT and
successors you can run a service as a different user. Make it one with
limited rights. Make sure the core of the system has its access
permissions tightened up so that the restricted-rights user can not
get at things it shouldn't.
<h3>Monitor Load</h3>
To track DoS attacks, a load monitor is useful. <tt>AxisBaseServlet</tt>
tracks the number of callers inside its subclasses at any point in time;
the <tt>AdminServlet</tt> shows how to get at this data.
<h3>Consider 'tripwire' and 'honeypot' endpoints</h3>
With the core endpoints moved, why not create tripwire implementations
of the admin endpoint, or a spoof endpoint listing under Axis/AdminServlet
pointing to a honeypot endpoint that does nothing but send an alert when
anyone sends a SOAP message to it. You then need a policy to act on the
alerts, of course. A real honeypot would emulate an entire back end
service -it would be an interesting little experiment to build and play
with.
<h2>What to do if you find a security hole in Axis</h2>
These days a lot of people love to make a name for themselves by finding
security holes, and Axis, as part of the Apache product family, is a
potential target. A hole in Axis could make many Web Services
vulnerable, so could be serious indeed. So far we have only found a few
of these, primarily in quirks of XML parsing rather than anything else.
<ol>
<li> Don't Panic. We have a process in place for verifying and fixing
holes.
<li> Don't rush to issue the press release to BugTraq. It is polite to
let us know, and even verify that you are correct.
<li> Test against the latest CVS version, not the (older) release
builds. We may like already have fixed it, hacker dudes :-)
<li> Email [EMAIL PROTECTED] Not the public axis-dev list, not
bugzilla. The security alias list is a list with representives from all
Apache projects, so your report will be taken seriously.
<li> Let us do a fix if possible, so we can announce that a fix is ready
when you announce your finding. This doesn't take any of the credit way
from the finder, just stops people panicing.
</ol>
<h3>Conclusions</h3>
We have shown some of the issues with Web Service security, things
you need to think of in your own service, and how to harden Axis itself.
Securing a system is much harder than getting a system to work, as
'work' usually means 'one or two non-critical bugs are OK'. From a
security perspective, no security holes can exist for a system to be
secure: no matter how obscure it is, someone may find it and exploit it.
Be paranoid: you know it makes sense.
