A few months ago I switched jobs. For my new job, I take the Washington Metropolitan Transit Authority Train (Metro) to go to my work location. Everyday it is a different experience. I get on a different train, a different car, sit on a different seat, sit next different people. Sometimes I get an announcement on the Metro that states the the train is delayed for some sort of reason. When my train is delayed then I usually send an email to my boss or call my wife that I will be late for dinner. I also see Metro law enforcement agents, who look for suspicious activities, people or items, get into the Metro and get off the Metro. Why are my observations about Metro interesting?Well, let's say that I am a XML message and I am sent as a response message from the service providing application. All I, as the XML message, do is sit still in a ESB process (the train) and ride the ESB (Metro equivalent in a SOA environment). I might ride the ESB process with other XML entities who join me during the process. An system owner or an enterprise owner would be comfortable if some sort security mechanisms would be implemented in the ESB where my (as an XML message), fidelity is not altered and copies of myself are covertly created and sent to shady destinations. To address this issue, the system owners should enforce polices of having security agents who act as listeners in the ESB and then call other agents who take care of the corrupt XML individual. As an innocent XML message, I don't want to be tampered with and I would be happy if security controls like agents were implemented on the ESB. I would be upset if my train (the ESB process) is significantly delayed if every security agent is "frisking" every XML message. My owner, the system, would then have to send notices to his customers that I arrived late to the appropriate destination because i was frisked way too many times. Security in the ESB and in the enterprise have to appropriate implemented without significantly slowing down the system.
In airports, we are asked to take off our jackets, shoes, pocket change, cellphones, etc, and etc. This is very inconvenient however we do this because we want to be sure that there are no bad guys on the plane. Even if they are in the plane then they are stripped off of their potential weapons at the airport. This way we know we can reach our destination without much trouble. Using this example, I would like to argue how binary XML is a bad technologies for ESB centric solutions. Since SOA systems are based on distributed archtiectures where trust plays an important role between stakeholders and their systems. If binary XML or even compressed XML is sent across an ESB then rogue agents might sent encrypted viruses and other malicious malware through the ESB. If the ESB decides to decrypt the message then it could possibly infect the whole middleware infrastructure. If it doesn't then the service consumer may be "hosed". This model could bring an enterprise if the malware message sent to several destinations if the message is sent in publish/subscribe model.
Therefore binary XML is a dangerous technology and it should be used in a minimal basis. If you don't think so then please comment to my post.
3 comments:
Enoch,
This is an interesting analogy. Thanks for posting it and inviting comments from those that disagree. I'll have to take you up on that. :-) In particular, I disagree with your assertions that there is some relationship between binary XML and the ability of rouge agents to send viruses or malware.
It is just as easy for a rouge agent to insert malicious code into a text XML message as it is to insert it into a binary XML message. In fact, quite a large range of viruses and malware are transmitted using text-based protocols like SMTP (e-mail) and HTML (web). Like XML, these protocols allow one to include text-based scripts (e.g., JavaScript) or "attach" binary data using a text encoding like base64 or binHex.
The malicious code problem is not caused by the text or binary data format used to transmit messages in your system. It is caused by the applications or infrastructure code that process these messages. In particular, it is caused by applications or infrastructure code that interpret a portion of the message as code and execute that code without the user's permission. Applications or infrastructure code may do this by design (e.g., via a script tag) or inadvertantly due to a software error exploited by the hacker (e.g., a stack overflow that corrupts the application).
In either case, the source of this problem is the application or infracture code, not the message format. The problem can occur whether you are using text or binary XML. And the problem is fixed by changing the application, not changing the message format.
I hope this helps to clarify the nature of malicious code and its relationship to the message format used in your system.
Cheers,
John
John,
Thanks for taking your time to read my post. I do agree with you that the message itself is not malicious. I however don't think binaryXML is the ideal format for true SOA centric solution. BinaryXML is ideal for point to point services and binaryXML is ideal for transporting imagery information. Thoughts?
- enoch
Enoch,
You're welcome. Thanks again for starting the conversation.
Actually, SOAs are one of the primary use cases for binary XML. See the W3C use cases Web Services within the Enterprise and Web Service for Small Devices for more information. There are also commercial binary XML products targetted specifically at optimizing existing SOAs for improved performance, higher throughput and reduced bandwidth utilization. E.g., see Efficient XML Web Services.
All the best!,
John
Post a Comment