WSO2EI: Verhinderung von HTTP-Headern in HTTP-Responses

Die Richtlinien für die Administration von WSO2-Produkten enthalten security¹-Empfehlungen für die Produktionsumgebung. Es wird empfohlen, den Standardwert „Server“ des Produkts zu aktualisieren, um zu verhindern, dass Informationen über den WSO2-Produktstapel durch HTTP-Header-Responses preisgegeben werden. Diese Empfehlung sollte meines Erachtens auch für HTTP-Header von „eigentlichen“ Backend-Services gelten. In diesem Blogbeitrag werde ich demonstrieren, wie man die Offenlegung von HTTP-Headern von Backend-Services in WSO2 EI-Proxy-Responses verhindern kann. Außerdem zeige ich, wie diese Lösung mit den Anforderungen eines SOAPv1.2-Proxy-Services kollidieren kann.

Der Proxy

Der folgende Beispiel-Proxy-Service gibt mit Hilfe eines Respond-Mediators die Ausgabe eines Call-Mediators an den anfragenden Client zurück. Wie erwähnt, erwartet der Client einen SOAPv1.2-Envelope in der Response. Nachfolgend sind die Proxy-Konfigurationen aufgeführt:

<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse" name="secureResponseProxy" startOnLoad="true" statistics="disable" trace="disable" transports="https">
   <target faultSequence="fault">
      <inSequence>
         <log level="full"/>
         <property expression="//*[local-name()='OrgNumber']"
name="OrganizationNumber" scope="default" type="STRING"/>
         <payloadFactory media-type="xml">
            <format>
               <web:GetOrganization
xmlns:web="http://example.organization.com">
                  <orgNumber>$ctx:OrganizationNumber</orgNumber>
               </web:GetOrganization>
            </format>
            <args/>
         </payloadFactory>
         <header name="Action" scope="default" value="http://example.organization.com/GetOrganization"/>
         <call>
            <endpoint key="organizationEndpoint"/>
         </call>
         <xslt key="transform_organiztaion_out.xslt"/>
         <property name="MESSAGE_FORMAT" value="soap12"/>
         <property action="remove" name="EXCESS_TRANSPORT_HEADERS" scope="axis2"/>
         <property action="remove" name="TRANSPORT_HEADERS"
scope="axis2"/>
         <respond/>        
      </inSequence>
      <outSequence>
         <send/>
      </outSequence>
   </target>
   <parameter name="disableSOAP11">true</parameter>
   <description/>
</proxy>

Dieser einfache Proxy ermittelt eindeutig eine Organisationsnummer aus der eingehenden Anfrage. Diese Daten werden dann in eine Payload-Transformation an den Backend-Service übergeben. Die Rückmeldung des Backend-Calls wird dann in den Mediations-Prozess eingefügt und anschließend durch einen XSLT-Mediator transformiert, bevor ein Respond-Mediator sie an den Client zurücksendet.

Der Leitfaden: Verhinderung der Offenlegung von Backend-HTTP-Headern

Mithilfe der generic properties²  TRANSPORT_HEADERS und EXCESS_TRANSPORT_HEADERS werden die mit der Backend-Response zurückgegebenen HTTP-Header entfernt, bevor die Nachricht an den Client zurückgeht. Dieses Sicherheitsmerkmal wird in der folgenden Zeile des Proxy-Service deutlich. 

<property action="remove" name="TRANSPORT_HEADERS" scope="axis2"/>

Es gibt auch Szenarien, in denen Backend-Services zusätzliche Informationen in den HTTP-Responses zurückgeben können (z. B. Cookie-Daten). Diese überflüssigen Daten werden von der TRANSPORT_HEADERS-Eigenschaft bei der Durchführung der Entfernungsaktion ignoriert. In diesen Fällen sollte die Eigenschaft EXCESS_TRANSPORT_HEADERS hinzugefügt werden, um die Offenlegung solcher Informationen zu verhindern.   

<property action="remove" name="EXCESS_TRANSPORT_HEADERS" scope="axis2"/>

Der Haken: Response mit SOAPv1.2

Wie bereits erwähnt, verlangt der Client SOAPv1.2 in der Response des Proxys. Die Service-Definition trägt dieser Anforderung Rechnung, in dem sie SOAPv1.1 mit dem Parameter disableSOAP11 deaktiviert. Allerdings hat der Prozess des Entfernens der Transport-Header den zusätzlichen Effekt, dass die Nachricht im Vermittlungsprozess auf den Standard zurückgesetzt wird.

In einem solchen Fall könnte man die Eigenschaft MESSAGE_FORMAT mit dem Wert soap12 zur Mediation der Nachricht hinzufügen und das Problem wäre gelöst.  Diese „mögliche“ Lösung hat auch den zusätzlichen Effekt, dass die Antwort vom Proxy immer ein SOAPv1.2-Envelope ist.

<property name="MESSAGE_FORMAT" value="soap12"/>

Der Nachteil bei dieser Lösung ist, dass sie nur funktioniert, wenn die Eigenschaften TRANSPORT_HEADERS und EXCESS_TRANSPORT_HEADERS nicht mehr Teil der Sequenz sind. Damit wird der eigentliche Gedanke der Sicherheitshinweise zunichte gemacht.

Der Gedanke: alternativer Ansatz

Nun, ich weiß, was Sie denken: „Wie wäre es mit einem alternativen Ansatz mit einem Loopback-Mediator anstelle des Respond-Mediators.  Anschließend ein Standardendpunkt in der outSequence mit einem Formatattribut von SOAPv1.2 und voila! Oder wie wäre es mit der Verwendung der Eigenschaften messageType und ContentType, um den Nachrichteninhalt in der Mediation zu ändern?

<send>
    <default format="soap12" statistics="enable" trace="enable">
        <timeout>
            <duration>60000</duration>
            <responseAction>fault</responseAction>
        </timeout>       
     </default>
   </send>

Fazit

Die Lösung für das hier vorgestellte Szenario ist, so lobenswert der Gedanke auch ist, ein Content-type Header, der direkt vor dem Respond-Mediator im Proxy-Dienst auf den Transportbereich gesetzt wird.

<header name="Content-Type" scope="transport" value="text/xml"/> 

Dieser Mediator ist nicht mit der ContentType-Property zu verwechseln, die in der Regel im Axis2-Bereich festgelegt wird. Zusätzlich zu den Unterschieden bei der Benennung und dem Geltungsbereich werden Sie, wenn Sie sich angewöhnt haben, den Wert Content-Type zur Unterscheidung zwischen SOAPv1.2 (application/soap+xml) und SOAPv1.1 (text/xml) zu verwenden, feststellen, dass diese Unterscheidung in diesem Zusammenhang nicht gilt. 

Referenzen: