XML complexity introduces security risks |
 |
By Michael S. Mimoso, Senior News Editor
17 Nov 2004 | SearchWebServices.com |
|
|
WASHINGTON -- XML security isn't all about shady crackers, malicious code and computer crime for profit -- not yet anyway.
Instead it's about removing complexity and remedying performance degradation introduced by hefty authentication methods, experts and users said Tuesday at XML Conference & Exposition 2004.
"Performance is a big issue for us and our clients," said Joon Lee, a consultant with McDonald Bradley Inc. of Herndon, Va. "Once you start signing (message) headers and bodies, that takes a lot of work that some of the software just can't handle in real time. It's a big challenge."
With XML acting as the primary data model for Web services transactions, architects and IT managers have to take these issues into consideration when designing and managing XML Web services.
Mark O'Neill, chief technical officer at Vordel Ltd., a Web services security vendor in Dublin, Ireland, explained during a session that security touches every layer of a Web service, from the consumer end to the access layer, service orientation, adapters and business logic. O'Neill said many enterprises may be tempted to code and configure security policies for every layer, but that introduces potentially dangerous complexity.
"You run into the possibility of mixing up your business logic and security logic," O'Neill said.
Instead, he said companies should design security as a service and deploy them either at a perimeter gateway or a Web services endpoint.
Access control is a security issue as well if enterprises decide to expose their Web services across the firewall to partners, suppliers and customers. O'Neill said enterprises should restrict the consumption and exposure of Web services to closed user groups. Using authentication technologies like digital signatures and public key infrastructure, and standards like SAML, companies can open their services in a paradigm similar to an XML-based virtual private network.
"Don't create a silo of users," O'Neill said. "Use your existing policy stores and extranets, and choose the solution that interoperates with the identity management you have."
While performance and authentication may introduce risk, crackers aren't exempt from wreaking havoc in the XML world. Though some of the threats are theoretical and not yet in the wild, others like inadvertent XML denial-of-service attacks (XDoS), are taking down services.
"The only thing we've run into are the DoS attacks, and those were resolved by coding in a timestamp," Lee said. "Most of them are inadvertent attacks. But SOAP and XML are relatively new; they haven't been around long enough to hack."
SOAP and XML Web services are the next attack vectors, O'Neill said. They are liable to cross-site scripting vulnerabilities, cookie poisoning attacks and changes to URL parameters, just like traditional computing.
"XDoS attacks are DTD [document type definitions] external entity attacks," O'Neill said. "They relay on an XML parser supporting DTD. They're generally called SOAP bombs. They expand hugely."
Other threats to XML can expose data contained in Web services messages, and attackers can use available inspection tools to their advantage. For example, WS-Inspection -- an IBM-led specification that inspects a site for available services and how that information should be made public , according to IBM -- can be turned around and used to determine the vulnerability of a service. DISCO, a Microsoft technology for publishing and discovering Web services, can be used to reveal a list of Web services, their WSDLs and schema stored on a server.
"As SOA matures, more of these threats are going to pop up," Lee said.
|
|
|
|
