Errormessage anpassen bei Xml Entity injection mit SOAP Request

Dom Wieser Gast #7028166
Lesenswert?
• ▲
▼ 
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
1
<?xml version="1.0" encoding="UTF-8"?>

2
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>

3
<stockCheck><productId>&xxe;</productId></stockCheck>


SOAP Error message ist folgende und wird erfolgreich abgewehrt:
1
...

2
AxisFault

3
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException

4
faultSubcode:

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

6
faultActor:

7
faultNode:

8
faultDetail:

9
{http://xml.apache.org/axis/}stackTrace:org.xml.sax.SAXException: Processing instructions are not allowed within SOAP messages

10
at org.apache.axis.encoding.DeserializationContext.startDTD(DeserializationContext.java:1161)

11
at org.apache.xerces.parsers.AbstractSAXParser.doctypeDecl(Unknown Source)

12
at org.apache.xerces.impl.dtd.XMLDTDValidator.doctypeDecl(Unknown Source)

13
at org.apache.xerces.impl.XMLDocumentScannerImpl.scanDoctypeDecl(Unknown Source)

14
at org.apache.xerces.impl.XMLDocumentScannerImpl$PrologDispatcher.dispatch(Unknown Source)

15
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)

16
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)

17
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)

18
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)

19
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)

20
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)

21
at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)

22
at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)

23
at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)

24
at org.apache.axis.Message.getSOAPEnvelope(Message.java:424)

25
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:

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


Auf z.B.
1
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.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Ben B. (Firma: Funkenflug Industries) #7028729
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Dom Wieser Gast #7028906
Lesenswert?
• ▲
▼ 
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:

1
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Ben B. (Firma: Funkenflug Industries) #7028958
Lesenswert?
• ▲
▼ 
> 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).
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren