Author: veithen
Date: Sun Mar 25 14:16:48 2012
New Revision: 1305043
URL: http://svn.apache.org/viewvc?rev=1305043&view=rev
Log:
Migrated a document to the new Axis site.
Added:
axis/axis1/java/trunk/src/site/xdoc/security.xml
- copied, changed from r1304929,
webservices/axis/trunk/site/src/java/src/documentation/content/xdocs/java/security.xml
Removed:
axis/axis1/java/trunk/docs/security.html
Copied: axis/axis1/java/trunk/src/site/xdoc/security.xml (from r1304929,
webservices/axis/trunk/site/src/java/src/documentation/content/xdocs/java/security.xml)
URL:
http://svn.apache.org/viewvc/axis/axis1/java/trunk/src/site/xdoc/security.xml?p2=axis/axis1/java/trunk/src/site/xdoc/security.xml&p1=webservices/axis/trunk/site/src/java/src/documentation/content/xdocs/java/security.xml&r1=1304929&r2=1305043&rev=1305043&view=diff
==============================================================================
---
webservices/axis/trunk/site/src/java/src/documentation/content/xdocs/java/security.xml
(original)
+++ axis/axis1/java/trunk/src/site/xdoc/security.xml Sun Mar 25 14:16:48 2012
@@ -1,61 +1,37 @@
<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN"
"./dtd/document-v12.dtd">
-<document>
- <header>
- <title>WebServices - Axis</title>
- </header>
+<!--
+ ~ Licensed to the Apache Software Foundation (ASF) under one
+ ~ or more contributor license agreements. See the NOTICE file
+ ~ distributed with this work for additional information
+ ~ regarding copyright ownership. The ASF licenses this file
+ ~ to you under the Apache License, Version 2.0 (the
+ ~ "License"); you may not use this file except in compliance
+ ~ with the License. You may obtain a copy of the License at
+ ~
+ ~ http://www.apache.org/licenses/LICENSE-2.0
+ ~
+ ~ Unless required by applicable law or agreed to in writing,
+ ~ software distributed under the License is distributed on an
+ ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ ~ KIND, either express or implied. See the License for the
+ ~ specific language governing permissions and limitations
+ ~ under the License.
+ -->
+<document xmlns="http://maven.apache.org/XDOC/2.0";
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+ xsi:schemaLocation="http://maven.apache.org/XDOC/2.0
http://maven.apache.org/xsd/xdoc-2.0.xsd";>
+ <properties>
+ <title>Web Service Security</title>
+ </properties>
<body>
-<a name="WebServiceSecurity"/>
-<section>
-<title>Web Service Security</title>
-
-<a name="TableOfContents"/>
-<section>
-<title>Table of Contents</title>
+<section name="Table of Contents">
-<ul>
- <li><a href="#TheChallengeOfServerSecurity">The challenge of server
security</a></li>
- <li><a href="#IsSOAPFundamentallyInsecure">Is SOAP fundamentally
insecure?</a></li>
- <li><a href="#CommonAttackTypes">Common Attack Types</a></li>
- <ul>
- <li><a href="#SpecialXMLAttacks">Special XML attacks</a></li>
- </ul>
- <li><a href="#AuthenticatingTheCaller">Authenticating the caller</a></li>
- <li><a href="#SecuringYourServices">Securing your Services</a></li>
- <ul>
- <li><a href="#XMLAttacks">XML attacks</a></li>
- <li><a href="#SessionTheft">Session Theft</a></li>
- <li><a href="#DOSAttacksViaLoad-intensiveOperations">DOS attacks via
load-intensive operations</a></li>
- <li><a href="#ParameterAttacks">Parameter Attacks</a></li>
- <li><a href="#CrossSiteScripting">Cross Site Scripting</a></li>
- </ul>
- <li><a href="#SecuringAxis">Securing Axis</a></li>
- <ul>
- <li><a href="#Disguise">Disguise</a></li>
- <li><a href="#CutDownTheBuild">Cut down the build</a></li>
- <li><a href="#RenameThings">Rename things</a></li>
- <li><a href="#StopAxisServletListingServices">Stop AxisServlet listing
services</a></li>
- <li><a href="#KeepStackTracesOutOfTheResponses">Keep stack traces out of
the responses</a></li>
- <li><a href="#StopAutogeneratingWSDL">Stop autogenerating WSDL</a></li>
- <li><a
href="#Servlets2.3UseFiltersForExtraAuthentication">Servlets2.3UseFiltersForExtraAuthentication</a></li>
- <li><a href="#LogThings">Log things</a></li>
- <li><a href="#RunAxisWithReducedJavaRights">Run Axis with reduced Java
rights</a></li>
- <li><a href="#RunTheWebServerWithReducedRights">Run the web server with
reduced rights</a></li>
- <li><a href="#MonitorLoad">Monitor Load</a></li>
- <li><a href="#ConsiderTripwireAndHoneypotEndpoints">Consider 'tripwire'
and 'honeypot' endpoints</a></li>
- <li><a href="#MonitorTheMailingLists">Monitor the Mailing Lists</a></li>
- </ul>
- <li><a href="#WhatToDoIfYouFindASecurityHoleInAxis">What to do if you find a
security hole in Axis</a></li>
- <li><a href="#AutomateSecurityTests">Automate Security Tests</a></li>
- <li><a href="#Conclusions">Conclusions</a></li>
-</ul>
+<macro name="toc"/>
</section>
-<a name="TheChallengeOfServerSecurity"/>
-<section>
-<title>The challenge of server security</title>
+<section name="The challenge of server security">
<p>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>
@@ -63,9 +39,7 @@
</section>
-<a name="IsSOAPFundamentallyInsecure"/>
-<section>
-<title>Is SOAP fundamentally insecure?</title>
+<section name="Is SOAP fundamentally insecure?">
<p>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.</p>
@@ -75,9 +49,7 @@
</section>
-<a name="CommonAttackTypes"/>
-<section>
-<title>Common Attack Types</title>
+<section name="Common Attack Types">
<ul>
<li>Denial of Service to a server</li>
@@ -89,11 +61,10 @@
</ul>
<p>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.</p>
+
<p>There is a large body of literature which covers securing web sites, such
as the <a href="http://www.owasp.org/";>Open Web Application Security
Project</a> Top Ten List of vulnerabilities, and their Guide to Building Secure
Web Applications.</p>
-<a name="SpecialXMLAttacks"/>
-<section>
-<title>Special XML attacks</title>
+<subsection name="Special XML attacks">
<p>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.</p>
@@ -108,13 +79,11 @@ Here you declare an entity referring to
<p>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 same
XML.</p>
-</section>
+</subsection>
</section>
-<a name="AuthenticatingTheCaller"/>
-<section>
-<title>Authenticating the caller</title>
+<section name="Authenticating the caller">
<p>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>
@@ -129,41 +98,31 @@ authentication stuff. Although the forms
</section>
-<a name="SecuringYourServices"/>
-<section>
-<title>Securing your Services</title>
+<section name="Securing your Services">
<p>One of the key security holes in any Web Service is the code you write
yourself. It won't 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>
<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.</p>
-<a name="XMLAttacks"/>
-<section>
-<title>XML attacks</title>
+<subsection name="XML attacks">
<p>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.</p>
-</section>
+</subsection>
-<a name="SessionTheft"/>
-<section>
-<title>Session Theft</title>
+<subsection name="Session Theft">
<p>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.</p>
-</section>
+</subsection>
-<a name="DOSAttacksViaLoad-intensiveOperations"/>
-<section>
-<title>DOS attacks via load-intensive operations</title>
+<subsection name="DOS attacks via load-intensive operations">
<p>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.</p>
-</section>
+</subsection>
-<a name="ParameterAttacks"/>
-<section>
-<title>Parameter Attacks</title>
+<subsection name="Parameter Attacks">
<p>If any parameter in the XML is fed straight into a database query, or some
other routine that depends on valid data, then that data <i>must</i> be
validated. Otherwise someone malicious could send a database update request, or
some other string which lets a malicious user manipulate the system. This could
even be as simple as changing their UserID in a request from that they set up
in the session. Database attacks come from any situation
where a parameter is inserted into an SQL query; the insertion of a semicolon
";" often permits the caller to append a whole new SQL command to the end of
the first, and have it executed with the rights of the Web Service.</p>
@@ -172,133 +131,101 @@ where a parameter is inserted into an SQ
<p>Note that this would seem to argue strongly against mapping Session EJB
objects to SOAP Endpoints. This is not the case. The Session bean must merely
assume that all incoming data is untrusted, and so validate it all before
processing further. This is exactly the kind of task a <a
href="http://martinfowler.com/eaaCatalog/serviceLayer.html";><i>Service
Layer</i></a> should be doing.</p>
-</section>
+</subsection>
-<a name="CrossSiteScripting"/>
-<section>
-<title>Cross Site Scripting</title>
+<subsection name="CrossSiteScripting">
<p>In theory, a pure Web Service should be immune to XSS attacks, at least
those that rely on having uploaded script displayed in an HTML Web Page
server-side, script that is executed when the client views it. But the moment
one takes Axis and integrates with one's own webapplication, any loopholes in
the rest of the webapp expose this exact problem. We don't think Axis itself is
vulnerable, because although it may include supplied data in a SOAPFault, this
is displayed as XML, not HTML. Clients which don't distinguish the two could be
an issue, as could anything we missed, especially in GET handling.</p>
-</section>
+</subsection>
</section>
-<a name="SecuringAxis"/>
-<section>
-<title>Securing Axis</title>
+<section name="Securing Axis">
<p>A core philosophy is 'defend in depth', with monitoring for trouble.</p>
-<a name="Disguise"/>
-<section>
-<title>Disguise</title>
+<subsection name="Disguise">
<p>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. While obscurity on its own is
inadequate; it can slow down attacks or make you seem less vulnerable to known
holes.</p>
-</section>
+</subsection>
-<a name="CutDownTheBuild"/>
-<section>
-<title>Cut down the build</title>
+<subsection name="Cut down the build">
<p>Rebuild Axis without bits of it you don't 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.</p>
-</section>
+</subsection>
-<a name="RenameThings"/>
-<section>
-<title>Rename things</title>
+<subsection name="Rename things">
<p>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.</p>
-</section>
+</subsection>
-<a name="StopAxisServletListingServices"/>
-<section>
-<title>Stop AxisServlet listing services</title>
+<subsection name="Stop AxisServlet listing services">
<p>To do this, set the Axis global configuration property
<code>axis.enableListQuery</code> to false.</p>
-</section>
+</subsection>
-<a name="KeepStackTracesOutOfTheResponses"/>
-<section>
-<title>Keep stack traces out of the responses</title>
+<subsection name="Keep stack traces out of the responses">
<p>By default, Axis ships in <i>production</i> mode; stack traces do not get
sent back to the caller. If you set <code>axis.development.system</code> 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.</p>
-</section>
+</subsection>
-<a name="StopAutogeneratingWSDL"/>
-<section>
-<title>Stop autogenerating WSDL</title>
+<subsection name="Stop autogenerating WSDL">
-<p>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#IndividualServiceConfiguration">reference</a>, to
return a WSDL resource which is simply an empty <wsdl/> tag.</p>
+<p>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_Configuration">reference</a>, to
return a WSDL resource which is simply an empty <wsdl/> tag.</p>
-</section>
+</subsection>
-<a name="Servlets2.3UseFiltersForExtraAuthentication"/>
-<section>
-<title>Servlets2.3: use filters for extra authentication</title>
+<subsection name="Servlets2.3: use filters for extra authentication">
<p>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.</p>
-</section>
+</subsection>
-<a name="LogThings"/>
-<section>
-<title>Log things</title>
+<subsection name="Log things">
<p>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.</p>
-</section>
+</subsection>
-<a name="RunAxisWithReducedJavaRights"/>
-<section>
-<title>Run Axis with reduced Java rights</title>
+<subsection name="Run Axis with reduced Java rights">
<p>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.</p>
-</section>
+</subsection>
-<a name="RunTheWebServerWithReducedRights"/>
-<section>
-<title>Run the web server with reduced rights</title>
+<subsection name="Run the web server with reduced rights">
<p>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.</p>
-</section>
+</subsection>
-<a name="MonitorLoad"/>
-<section>
-<title>Monitor Load</title>
+<subsection name="Monitor Load">
<p>To track DoS attacks, a load monitor is useful.
<code>AxisBaseServlet</code> tracks the number of callers inside its subclasses
at any point in time; the <code>AdminServlet</code> shows how to get at this
data.</p>
-</section>
+</subsection>
-<a name="ConsiderTripwireAndHoneypotEndpoints"/>
-<section>
-<title>Consider 'tripwire' and 'honeypot' endpoints</title>
+<subsection name="Consider 'tripwire' and 'honeypot' endpoints">
<p>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.</p>
-</section>
+</subsection>
-<a name="MonitorTheMailingLists"/>
-<section>
-<title>Monitor the Mailing Lists</title>
+<subsection name="Monitor the Mailing Lists">
<p>We tend to discuss security on Axis-Dev, whenever it is an issue, but if
demand is high we may add an axis-announce mailing list for important
announcements.</p>
-</section>
+</subsection>
</section>
-<a name="WhatToDoIfYouFindASecurityHoleInAxis"/>
-<section>
-<title>What to do if you find a security hole in Axis</title>
+<section name="What to do if you find a security hole in Axis">
<p>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.</p>
@@ -312,17 +239,13 @@ where a parameter is inserted into an SQ
</section>
-<a name="AutomateSecurityTests"/>
-<section>
-<title>Automate Security Tests</title>
+<section name="Automate Security Tests">
<p>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.</p>
</section>
-<a name="Conclusions"/>
-<section>
-<title>Conclusions</title>
+<section name="Conclusions">
<p>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.</p>
@@ -330,7 +253,5 @@ where a parameter is inserted into an SQ
</section>
-</section>
-
</body>
</document>
