Security Vulnerabilities in Apache Axis2 1.4 / Rampart 1.4 and Avoiding Them

Introduction

The release of Axis2 1.4 introduced the policy configuration at binding level facility that's been long awaited. Now, with Axis2 1.4 you can define policies using binding hierarchy at binding level, binding operation level and binding message level. However, if you configure security using the new configuration, it makes services vulnerable, exposing the service in an unsecure manner for some End Point References (EPR).  

Applies To

Table of Contents

• Why Do Services Become Vulnerable When Using Policy Configurations at Binding Hierarchy ?
• Problems with the old policy configuration with Axis2 1.4 ?
  • Generated WSDL violates WS - Security Policy Specification
  • Work Around for Incorrect WSDL Issue
  • Code Generated Stubs Against Axis2 1.4 Generated WSDL Doesn’t Contain the Policies
  • Work Around for the Stubs without Policies
• Summary
• References
  

Why Do Services Become Vulnerable When Using Policy Configurations at Binding Hierarchy ?

So let's take the version service founf in Axis2 as an example. In Aixs2 1.4, it is exposed in four EPRs.

1. SOAP 1.1 binding
   • http://myserver:8080/axis2/services/Version.VersionHttpSoap11Endpoint
2. SOAP 1.2 binding
   • http://myserver:8080/axis2/services/Version.VersionHttpSoap12Endpoint
3. HTTP binding
   • http://myserver:8080/axis2/services/Version.VersionHttpEndpoint
4. For backward compatibility  
   • http://myserver:8080/axis2/services/Version 

When policies are configured at binding-level for requests coming through EPR 1.) , 2.) and 3) using new policy configuration mechanism, Axis Engine will correctly set appropriate effective policies. However, if requests comes through EPR 4.), policies will not be set on request messages. So when it comes to Rampart module doing security validation, Rampart will consider the fact that there is no policy associated with the corresponding message and allow the message that doesn’t satisfy security requirements to consume the service.      

Due to the above reason, you SHOULD NOT use the new policy configuration found in Axis2 1.4 to configure security and should stick to the old way of configuration even with Axis2 1.4. You can find how to configure security using the old configurations, in the following tutorials listed below:

• Web Services Security with Apache Rampart – Part 1 ( Transport Level Security )
• Web Services Security with Apache Rampart – Part 2 (Message-Level Security)

Problems with the Old Policy Configuration in Axis2 1.4 ?

Now we will look at problems that arise as a result of appling polices using old configurations in Axis2 1.4.

Generated WSDL violates WS - Security Policy specification

When we configure policies using the old configurations, that is, when we attach policies to the service, operation, message elements in the services.xml, they are attached to the portType element WSDL generated in Axis2 1.4. In Axis2 1.4 if you need to attach policies to the binding, you are required to attach them using the new configurations introduced in Axis2 1.4, that allows you to attach policies to the binding hierarchy. But, as we discussed earlier we are not able to implement this due to security vulnerabilities. 

As an example, If we deploy the service I've used in the tutorial titled “ Web Services Security with Apache Rampart – Part 1 ( Transport Level Security )” using Axis2 1.3 and Axis2 1.4, the WSDLs generated would look like this.

• Axis2 1.3 generated WSDL
• Axis2 1.4 generated WSDL

As you can see below, in Axis2 1.3 generated WDSL, policies are attached to bindings.

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
                  xmlns:ns0="http://service.rampart.tutorial" >

    <wsdl:binding name="SecureServiceSOAP11Binding" type="ns0:SecureServicePortType">
        <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" Id="UTOverTransport">
            ...
        </wsp:Policy>
    </wsdl:binding>
    <wsdl:binding name="SecureServiceSOAP12Binding" type="ns0:SecureServicePortType">
        <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" Id="UTOverTransport">
            ...
        </wsp:Policy>
    </wsdl:binding>
        ...
</wsdl:definitions>

But if we look at Axis2 1.4 generated WSDL policies are attached to the port type.

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
        ...
    <wsp:Policy wsu:Id="UTOverTransport"
		xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
		xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

    </wsp:Policy>
        ...

    <wsdl:portType name="SecureServicePortType"
                   wsp:PolicyURIs="#UTOverTransport"
                   xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"  >
        ...
    </wsdl:portType>
        ...
</wsdl:definitions>

So does this really matter ? Yes, because WS - Security Policy specification specifically states not to attach security policies to the port type and they should appear in the bindings and this is a violation of what the specification is suggesting. For more information please refer to the section 4.2 – Policy Subjects in the WS - Security Policy specification.  What this means is we lose the interoperability between other WS Stacks.  And another problem is Axis2 code generator doesn’t attached these policies to the generated Stub when we code generate against the WSDL. This is discussed in the section "Code generated Stubs against Axis2 1.4 generated WSDL doesn’t contain the policies".   

Work around for incorrect WSDL issue

One work around would be to put the correct WSDL in to the service archive and configure Axis2 to use the original WSDL in the service archive. You can do this annotation in the WSDL generation correctly and redeploy using the use original parameter set in the services.xml as illustrated below:

<service name="MyService">
            ...
	<parameter name="ServiceClass" locked="false">com.wso2.training.MyService</parameter>
	<parameter name="useOriginalwsdl">true</parameter>
            ...
</service>

You should put correctly annotated MyService.wsdl file in to the META-INF directory in your service archive.

Now, let's look at the second issue if you use the WSDL generated by Axis2 1.4.

Code Generated Stubs Against Axis2 1.4 generated WSDL doesn’t contain the policies

Generally Axis2 code generator correctly attaches policies in the WSDL to the WSDL generated ( as described in the tutorial titled“ Web Services Security with Apache Rampart – Part 1 ( Transport Level Security )”. But when policies are attached to the port type as it is done in Axis2 1.4 generated WSDL, policies in the WSDL are not attached to the stub generated.

Work Around for the Stubs without Policies

Work around for this would be to inject policies from a policy file. In order to do this, you need to first extract the policy from the WSDL and save it as a file. For the example discussed, the policy file would look like this. Then you could create a policy object from that file using the following code:

    StAXOMBuilder builder = new StAXOMBuilder(path/to/policy/file);
    Policy clientPolicy = PolicyEngine.getPolicy(builder.getDocumentElement());

Then you can attach that policy using the following code:

ServiceClient sc = stub._getServiceClient();
sc.getAxisService().getPolicySubject().attachPolicy(clientPolicy);

Summary

You SHOULD NOT attach security polices to binding hierarchy using the new policy configuration introduced in Axis2 1.4, as this leads to exposing service with security threats. You can use the more older way of configuring security policies and use one of the work arounds whenever necessary.

References

1. Web Services Security with Apache Rampart – Part 1 ( Transport Level Security )
2. Web Services Security with Apache Rampart – Part 2 (Message-Level Security)
3. Applying policies at binding hierarchy in Apache Axis2 1.4
4. WS - Security Policy specification

Author

Nandana Mihindukulasooriya, Software Engineer, WSO2 Inc. nandana AT wso2 DOT com