Errormessage anpassen bei Xml Entity injection mit SOAP Request

[Dom Wieser (Gast)]

Hallo,

Wir verwenden einen alten Webservice (SOAP/WSDL) der noch auf dem Axis 
1.4 Framework basiert:
https://axis.apache.org/axis/java/developers-guide.html#Table_of_Contents

Wir haben einen Security Test (XML Entity Injection) durchgeführt, der 
erfolgreich war: wir haben einen Soap Request mit Processing 
Instructions abgesendet z.B.

https://portswigger.net/web-security/xxe

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck><productId>&xxe;</productId></stockCheck>

SOAP Error message ist folgende und wird erfolgreich abgewehrt:

...
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: org.xml.sax.SAXException: Processing instructions are not allowed within SOAP messages
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:org.xml.sax.SAXException: Processing instructions are not allowed within SOAP messages
at org.apache.axis.encoding.DeserializationContext.startDTD(DeserializationContext.java:1161)
at org.apache.xerces.parsers.AbstractSAXParser.doctypeDecl(Unknown Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.doctypeDecl(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl.scanDoctypeDecl(Unknown Source)
at org.apache.xerces.impl.XMLDocumentScannerImpl$PrologDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
at org.apache.axis.Message.getSOAPEnvelope(Message.java:424)
at org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)

Die Frage ist,  wie können wir den Fault String auf einen 
generalisierten (ohne Library details) anpassen? Denn dieser enthält 
gem. Security Tester zuviele Details, die einem Attacker helfen könnten:

faultString: org.xml.sax.SAXException: Processing instructions are not allowed within SOAP messages

Auf z.B.

faultString: Server Error

?

Habe schon viel versucht,  der Call kommt nicht mal in meine interne XML 
Parsing Klasse so dass ich da etwas machen könnte,  sondern dieser Call 
wird vom Framework sofort standardmäßig geblockt.

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

Hm, was ist da groß an Informationen enthalten, die einem Angreifer 
helfen könnten, bzw. die er nicht selber weiß?

Meiner Meinung nach muss man sich bei sowas darauf verlassen, daß das 
Framework bzw. die grundlegende Ebene von sich aus sicher ist. Man kann 
z.B. keinen HTML-Server mittels PHP sicher(er) machen, wenn der 
HTML-Server selbst schon unsicher ist.

[Εrnst B. (ernst)]

Ohne jetzt groß im Detail geguckt zu haben:
Sollte der Stacktrace nicht nur dann im Reply enthalten sein, wenn
(für das Axis-Servlet) isDevelopment() == true
wahr ist?
-> Auf "production" umkonfigurieren, nochmal testen.

[Dom Wieser (Gast)]

Ben B. schrieb:
> Hm, was ist da groß an Informationen enthalten, die einem Angreifer
> helfen könnten, bzw. die er nicht selber weiß?
Hi Ben, gute Frage.
Ich sehe das auch so. IT Security ist pingelig und bemängelt die vielen 
Infos im Stacktrace die einem Attacker helfen könnten,  noch mehr 
Informationen über die Webapp zu bekommen und härtere Angriffe 
durchzuführen..

Εrnst B. schrieb:
> Ohne jetzt groß im Detail geguckt zu haben:
> Sollte der Stacktrace nicht nur dann im Reply enthalten sein, wenn
> (für das Axis-Servlet) isDevelopment() == true
> wahr ist?
> -> Auf "production" umkonfigurieren, nochmal testen.
Hi Ben, danke ganz genau! Hab ich gemacht,  hat funktioniert!
Stacktrace ist nun weg und es sieht nur mehr so aus:

org.xml.sax.SAXException: Processing instructions are not allowed within SOAP messages

Jetzt hab ich das der Security Abteilung gezeigt und die sind immer noch 
nicht zufrieden!
Ihrer Meinung nach ist das "org.xml.sax.SAXException" schon zuviel Infos 
über die eingesetzten Libraries/Framework...😣

Ich habe gesagt,  Leute es ist genug, die  Error Meldung kann ich nicht 
abändern, die kommt direkt von der verwendeten Standard Lib bzw. 
Framework! Und kann man meines Wissens nicht übersteuern.

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

> Hi Ben, gute Frage.
> Ich sehe das auch so. IT Security ist pingelig und bemängelt die
> vielen Infos im Stacktrace die einem Attacker helfen könnten,
> noch mehr Informationen über die Webapp zu bekommen
> und härtere Angriffe durchzuführen..
Ist ja prinzipiell richtig, aber man muss bedenken, wie laufen solche 
Angriffe ab? Wenn das Ziel ausreichend attraktiv ist, probiert der 
Angreifer sowieso sein komplettes Portfolio daran aus. Security by 
obscurity war noch nie eine gute Idee, weil sie eine Sicherheit 
vortäuscht, die in Wirklichkeit gar nicht vorhanden ist. Das ist damit 
vergleichbar, daß der böse 1337 h4x0r vergeblich versuchen soll, das 
sehr gut gesichterte Gartentor zu knacken, nur weil er noch nicht 
gesehen hat, daß rechts und links davon der Zaun fehlt. Was denkst Du 
selbst, wie lange geht das gut und was passiert, wenn er sich einmal 
genauer umschaut?

Ich betrachte ein System erst dann als "sicher", wenn der Angreifer auch 
bei kompletter Kenntnis der Serverkonfiguration und evtl. sogar des 
Quellcodes der angegriffenen Anwendung nicht zum Ziel kommt solange ihm 
z.B. ein Admin-Kennwort fehlt (das Thema [sichere] 2FA mal außen vor 
gelassen).