Is it possible to disable DTD tags and/or Entity expansion when processing XML SOAP Requests through the WSS Agent?
For example this XML:
<!DOCTYPE order [
<!ENTITY xxe SYSTEM "file:///dev/random123" >
]>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Header>
</soap:Header>
<soap:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
&xxe;
</soap:Body>
</soap:Envelope>
Will result in this error in the soasm_agent.log:
81-a7194bc6 - SM_WSC_00077 - \n\tERROR caught: java.lang.IllegalStateException: SM_WSC_00069 - XML byte[] content cannot be c
onverted to Document\njava.lang.IllegalStateException: SM_WSC_00069 - XML byte[] content cannot be converted to Document
at b0.b(DashoA10*..)
at b0.b(DashoA10*..)
at az.getMessageBodyDOM(DashoA10*..)
at com.netegrity.tm.contenthelper.handler.message.SOAPEnvelopeHandler.b(DashoA10*..)
at com.netegrity.tm.contenthelper.handler.message.SOAPEnvelopeHandler.handleRequest(DashoA10*..)
at com.netegrity.tm.contenthelper.handler.MessageHandlerService.dispatchRequest(DashoA10*..)
at com.netegrity.tm.contenthelper.handler.HandlerServiceManager.dispatchRequest(DashoA10*..)
at com.netegrity.tm.contenthelper.handler.authentication.WSSecurityAuthHandler.b(DashoA10*..)
at com.netegrity.tm.contenthelper.handler.authentication.WSSecurityX509AuthHandler.doAuthRequest(DashoA10*..)
at com.netegrity.tm.contenthelper.handler.authentication.WSSecurityAuthHandler.handleRequest(DashoA10*..)
at com.netegrity.tm.contenthelper.handler.AuthenticationHandlerService.dispatchRequest(DashoA10*..)
at com.netegrity.tm.contenthelper.handler.HandlerServiceManager.dispatchRequest(DashoA10*..)
at com.netegrity.tm.contenthelper.helper.XMLContentHelper.gatherCredentials(DashoA10*..)
at com.netegrity.tm.ipc.XMLContentHelper_Ipc.c(DashoA10*..)
at com.netegrity.tm.ipc.XMLContentHelper_Ipc.processRequest(DashoA10*..)
at com.netegrity.tm.ipc.service.xmlsdkserver.XmlSdkDispatcherAndAssembler.processRequest_XMLContentHelper(DashoA10*..
)
at com.netegrity.tm.ipc.service.xmlsdkserver.XmlSdkDispatcherAndAssembler.dispatch(DashoA10*..)
at com.netegrity.tm.ipc.service.xmlsdkserver.XmlSdkDispatcherAndAssembler.run(DashoA10*..)
Caused by: java.io.FileNotFoundException: /dev/random123 (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:120)
at java.io.FileInputStream.<init>(FileInputStream.java:79)
at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)
at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
at org.apache.xerces.impl.XMLEntityManager.startEntity(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEntityReference(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.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.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:124)
... 18 more
The error is caused by: java.io.FileNotFoundException: /dev/random123 (No such file or directory)"
This is concerning as it means that the file system is read even before digital signatures are being validated.
There is a CA Advisory: Proactive_Notification_Advisory.docx; however, it doesn't mention WSS, or WSS Agent for Apache, or other related WSS agents or any issues with those.
https://communities.ca.com/docs/DOC-231168996
The issue above is now fixed with a new jar file based on the bug DE319724 fixed, -- which may be officially released beyond the release CA SSO R12.52SP1CR8. For immediate help with this issue, please contact CA Support.
Get the new jar file (soasmapi.jar.zip) from CA Support and unzip it.
* Stop services
- tmxmlsdkserver
- apache web server (with agent)
* Save/ Backup your current soasmapi.jar in
<wss_agent_home>/webagent/java
* Move the CA-supplied soasmapi.jar (with DevFix) into that directory.
* Bring up both
- tmxmlsdkserver
- apache web server
Test the XML use case above (e.g. with your application or SOAPUI). The WSS agent will not be searching for the file ("file:///dev/random123" ) any more in the local file system as before; no “...content cannot be converted to Document...” “ or "...No such file or directory..." message.
None.