02.25.05
It Can’t Happen Here?
As we’ve noted time and again, services-oriented architectures (SOAs) promise to do wonders for integration, both inside and outside the firewall. Reliance on loosely-coupled connections that survive software upgrades, declarative approaches that demystify the process of making connections, and the adoption of consensus standards such as SOAP messaging and XML identifiers and content, will make connectivity far more accessible than ever.
But here’s the rub. The strengths of SOAP and XML are also their greatest weaknesses. Because SOAP uses HTTP, which is designed to pass through firewalls, SOAP messages could provide attractive vectors for writers of all the evil malware that infects Windows PCs. And because XML is wordy and easy to manipulate, how much will it take for some hacker to design a payload that is so complex to parse that it could expose service providers denial of service attacks?
We were pondering this while walking the aisles of a recent web services conference for Wall St. Significantly, when we popped the question on whether there have ever been documented virus, worm, or denial of services attacks via web services, the stock answer was, “Nothing that’s been announced publicly.”
In all likelihood, there have probably been few if any attacks up until now because the vast worlds of Outlook address books and category killer sites like Amazon or Yahoo present meatier targets for hackers. But as enterprises expose higher value transactions through SOAs and web services, attackers bent on economic destruction rather than ego gratification are likely to shift their sights.
The immediate question is whether the basic building blocks of web services – SOAP and XML – are in their own way just as vulnerable as Windows and Internet Explorer. In Windows and IE, the problems are endemic to the platform; for web services, the vulnerability is the distributed nature of web services, the accessibility of the core building blocks (XML can be read by non-programmers), and the lack of mechanisms, best practices, or standards outside of identification or message authentication. Compounding matters, because web services are standards based, they are well suited for interchangeability. You can replicate, aggregate, or disaggregate service requests or service content. And XML itself is very resource-intensive. Bottom line? XML and SOAP could present inviting targets for hackers.
Of course, you can set policies limiting the size of XML payloads that are processed and other measures covering origin of requests, and so on. And you can devote an armada of specialized appliances for decryption, scanning, parsing, content or message routing, and other resource-intensive tasks. But just as clever programmers can defeat passwords and similar measures, manipulating XML to wreak havoc shouldn’t be rocket science. And, given that each of these tasks is usually handled by products from an array of hardware, software, and platform vendors, there is always the chance that cleverly constructed hacks could seep through the cracks.
To repeat, the sky is NOT yet falling down on the sanctity of web services. We’re encouraged by innovations, such as Sarvega’s approach to sniffing XML streams before they are assembled into documents. But sooner or later, hacks and malware will become reality, meaning that service requests are going to have to be vetted for threats far beyond requestor or message integrity.