Two XML Content Filtering Examples
Articles on XML security tend to focus on the theoretical. I guess this is fine for a new technology, where it is important to understand the concepts: things like message-level versus transport-level security. But there is nothing like a couple of real-world examples to focus matters. So, for a talk at the RSA Security Conference last week [warning - 3.5MB download!] on Web Services security, I included some examples. For those of you who didn't make the conference (which was excellent as ever), I've posted two of the examples to my blog.
The examples are designed to show that even though XML communication is new, the principles of defensive security haven't changed much over the years. As avenues of attack are blocked, attackers have moved further up the stack. First, implementations of the TCP/IP stack were attacked (e.g. Ping of Death). Next, Web Servers sitting on the TCP/IP stack were attacked (e.g. NIMDA). Then, Web applications running on the Web Server were attacked (e.g. Cross-Site Scripting). When SOAP is bound to HTTP, it's possible to see a SOAP-over-HTTP stack as an example of a Web application - in which case, SOAP services themselves are yet another layer of top of the SOAP stack. Defenses for all of these layers must be cumulative.
The first example attacks an XML Signature processing engine.
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://www.w3.org/2001/12/soap-envelope"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<env:Header>
<wsse:Security
wsse:actor="http://www.w3.org/2002/06/soap-envelope/role/next">
<wsse:BinarySecurityToken
wsse:Id="BestsellersToken"
wsse:ValueType="wsse:X5090v3"
wsse:EncodingType="wsse:Base64Binary">
asDVIWMI389MJmdn . . .
</BinarySecuritytoken>
<dsig:Signature>
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm=
“http://www.w3.org/2001/10/xml-exc-c14n#"/>
<dsig:SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<dsig:Reference URI =
"http://ardownload.adobe.com/pub/adobe/acrobatreader/win/5.x/5.1/AcroReader51_ENU_full.exe">
<dsig:Transforms>
<dsig:Transform Algorithm=http://www.w3.og/2000/09/xmldsig#enveloped-signature/>;
<dsig:Transform Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
</dsig:Reference>
</disg:SignedInfo>
<dsig:SignatureValue>
</dsig:SignatureValue>
<dsig:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI="#BestSellersToken"/>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
</wsse:Security></env:Header>
<env:Body>
<p:invoice ID="bookinvoice"
xmlns:p=http://bestsellers.com/invoice>;
<p:item>NewBook</p:item>
<p:number>1</p:number>
<p:price>15.25</p:price>
<p:shipto>Jane Doe</p:shipto>
</p:invoice>
</env:Body>
</env:Envelope>
Note the red text. For signed SOAP messages, it is conventional to leave the Reference URI blank, indicating that it is the body of the SOAP message which was signed. I've put the URL of an Adobe Acrobat 5.1 download into the reference URI instead. The XML Signature recommendation states that:
"XML signature applications MUST be able to parse URI syntax. We RECOMMEND they be able to dereference URIs in the HTTP scheme."
So for an XML Signature processor which is following the URI reference, this means that it must download a 20MB file and then compute the signature over it. This uses us the bandwidth of the target application, as well as locking threads in a long wait for the 20MB file to download.
But an XML Signature engine for a SOAP application does not have to blindly download data from any URI in a Reference element. That is because the XML Signature specification states that:
"Note, there may be valid signatures that some signature applications are unable to validate. Reasons for this include failure to implement optional parts of this specification, inability or unwillingness to execute specified algorithms, or inability or unwillingness to dereference specified URIs (some URI schemes may cause undesirable side effects), etc." [ XML-Signature Syntax and Processing - W3C Recommendation 12 February 2002 ]
So vulnerability to this bandwidth-clogging attack is unnecessary. Do the XML Signature engines in XML security tools guard against this type of attack? For tools which plug in a third-party XML Signature implementation, the answer is probably "no". For tools which ensure that their implementation of XML Signature is appropriate to XML communications from untrusted parties, the answer is "yes". I'm happy to report that VordelSecure falls into the latter camp.
The second example takes a technique from the world of Web application security: SQL Injection. Consider a SOAP message which contains an IBSN book serial number to be inserted into a database query to fetch book information. The incoming SOAP message might look like this:
Let's say this IBSN is then fed into VB.NET code that looks like this:
Set myRecordset = myConnection.execute("SELECT * FROM myBooksTable WHERE IBSN ='" & IBSN_Element_Text & "'")
This results in a SQL query like this:
SELECT * FROM myBooksTable WHERE IBSN = ‘1234567890’
Can you see what's coming next? What if my system receives a SOAP message like this one:
<SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/>
<SOAP-ENV:Header></SOAP-ENV:Header>
<SOAP-ENV:Body
<BookLookup:searchByIBSN xmlns:BookLookup=https://www.books.com/Lookup>
<BookLookup:IBSN>' exec master..xp_cmdshell 'net user Joe pass /ADD' --<BookLookup:IBSN>
</BookLookup:searchByIBSN>
</SOAP-ENV:Body></SOAP-ENV:Envelope>
Passing through the same VB.NET code, we get this SQL query:
SELECT * FROM myTable WHERE IBSN =‘’ exec master..xp_cmdshell 'net user Joe pass /ADD'--'
If my Web application is running as Administrator (inadvisable, but common), then this query creates a user called "Joe" with password "pass".
How can you guard against this attack? Firstly, it's important to follow best practice and not set yourself up for attack by running a Web application under administrator/superuser priveliges. Remember "there is no patch for stupidity", but there are precautions which can be taken. Sanity-checking on the incoming XML is advisable. XML Schema is used for this purpose. The following XML Schema fragment ensures that the incoming IBSN parameter is indeed a string containing ten integers:
<simpleType name="ibsn"> <restriction base="string"> <pattern value="[0-9]{10}"/> </restriction> </simpleType>
This Schema fragment should be processed against the data isolated by the following XPath expression:
//BookLookup:searchByIBSN/BookLookup:IBSN
This combination of XPAth and XML Schema ensure that "1234567890" passes the rules, while jiggery-pokery like "' exec master..xp_cmdshell 'net user Joe pass /ADD' --" fails. Applications which act as XML Firewalls/Gateways/Proxies, such as VordelSecure, implement this combination of XML Signature and XPath to isolate and validate XML content.
I hope that these two attacks illustrate that XML security isn't really anything new: attackers figure out what an application expects, then give it something it doesn't expect, to see what happens. And remember that XML security implementations themselves may also be attacked.
|
