| Article found | Fact |
|---|
|
XML / SOAP Web Services Security [Mü02]
|
- ältere Systeme rechnen eventuell nicht mit falsch formatierten Eingaben
- Parameter angeben, die die Maximallänge überschreiten
- Wildcards oder Escape-Zeichen einbauen
- Werte und Attribute mittels XML Schemas prüfen
|
|
Web Service Security [On02]
|
Web Services present a new avenue of attack into the enterprise. Even so, some of the
tactics are familiar: feeding unexpected data to an application in order to confuse it, or disable it.
packet. Web Services present details of their interface in WSDL files, which effectively say, "Here are the details of the data that I expect." This invites a hacker to send it inappropriate data in order to see what happens. A WSDL file may contain the following line:
<xsd:element name="tickerSymbol" type="string"/>
This indicates that one of the parameters expected by the Web Service is a string,
called "tickerSymbol." The options for a speculative attack on this Web Service would
include sending it a number instead of a string, or sending it a very large string
designed to overload the Web Service. It is important, therefore, that "sanity checks"
are performed on incoming data directed to Web Services. This may take the form of
checking SOAP parameters against an XML Schema. However, XML Schema validation
is processor-intensive. In addition, certain portions of a SOAP message may be volatile,
meaning that they change while in transit between the SOAP requester and the Web
Service. Volatile portions of a SOAP message include the header, which may contain
routing information that changes as the message is routed. Therefore, it is more
appropriate to use XPath to narrow down the data validation to nonvolatile portions
of the SOAP message.
|