Welcome Guest!
Create Account | Login
Locator+ Code:

Search:
FTPOnline
Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

email article
printer friendly
more resources

Make Your XML Secure
Applying security standards to XML will keep this essential part of Web services from becoming their downfall.
by Jason Bock

November 2002 Issue

For this solution: NET Framework

In the last five years, XML has evolved from an acronym that few understood to one that virtually everyone knows. For better or worse, it has worked its way into every corner of the typical IT shop. For example, you can use it to store information about a user's order, then send that data to the server for processing through applications such as BizTalk Server as an attachment in e-mail. During the order processing, BizTalk can call an object over the wire in an XML format through the Simple Object Access Protocol (SOAP) (see Figure 1).

Figure 1 Ship XML Data

Whatever form the data is in the XML document, it's clear that reading XML is fairly easy, even if you know nothing about it. For example, in Figure 1 you can see the (fictitious) credit card number in plain sight in the Number element, which is contained in the Payment element. Because the information is sent by e-mail and SOAP over HTTP, it's pretty easy for a hacker to snatch the data as it goes across the wire and determine what the credit card number is. Needless to say, this is undesirable. There needs to be a way to secure the data so sensitive information isn't disclosed to unintended recipients. In this article, I'll cover some emerging standards for securing XML and discuss how you can put them to use in your organization.

The problem isn't that SOAP itself is insecure or that the order-processing component has security issues. There are ways to make e-mail and HTTP communication secure with the S/MIME and HTTPS standards, and you can easily change the infrastructure to use these standards at the two data exchange points. The problems lie in other areas.

For example, it's not necessary to secure the entire XML document; all you need to do is encrypt portions of it. If the application passes data from the BizTalk Server to the order processing component over HTTPS, the entire document is encrypted. However, this process becomes inefficient when it encrypts 20 order items and all you really need is to encrypt the one Payment element. Similarly, you might only need to sign the credit card information (instead of the entire XML document) to prove that the card data came from you.

The industry needs standards to ensure all developers implement XML security in the same way. You can choose to roll out your own proprietary standard to handle security with XML documents. This works so long as you can manage the systems that handle the XML information. However, it's common these days to send data to other companies, where you have no control over the development team on the other side. Trying to convince them to handle your XML encryption schemes can be problematic at best. Furthermore, ensuring that a specification is virtually free of security holes is difficult. Fortunately, the W3C is well aware of the issues surrounding security in XML, and they've established standards to ensure everyone handles XML security issues in the same way (see Resources).

Back to top

Printer-Friendly Version











Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTP Home