The Differences Between an XML Gateway and a Web Application Firewall

Jason Macy, CTO  

Forum Systems, Inc

Introduction

A common industry misconception is understanding the differences between an XML Gateway and a Web Application Firewall.   These technologies are sometimes confused as being competitive, but in fact they are complementary technologies that together provider the foundation of modern-day network perimeter security infrastructure.

Key Areas of Comparison

To better understand the distinctions between these product technologies, the primary areas of comparison are as follows:

Topology

• Deployment Modes

Protocols and Message Formats

• Standards
• Protocols

Security

• Threat Mitigation
• Transaction Privacy
• Transaction Integrity

Identity

• Access Control
• SSO

Transaction Processing and Mediation

• Workflow
• Transformation / Mapping

WAF Topology

WAF technology has several deployment modes, but it is an important distinction from a gateway product that over 50% of WAF deployments are in non-inline mode, also known as passive mode.   The modes of deployment are:

• Non-Inline Mode (50% of deployments)
• Transparent Proxy
• Layer 2 Bridge
• Reverse Proxy

XML Gateway Topology

XML Gateways are always deployed in a reverse-proxy configuration where the gateway component terminates the connection and provides the security, identity, governance, and mediation functions at TCP Layer 4-7.  The reverse-proxy deployment paradigm is necessary since XML Gateways serve as a protocol break intermediary for traffic flow and have the ability to restrict and block traffic flow as needed.  Thus, the mode of deployment for XML Gateway is always:

• Reverse Proxy
• Service Mode (Request/Response directly to Gateway, which performs the business function)

Protocols and Message Formats

A WAF product focuses on different set of protocols and message formats than an XML Gateway technology product.   This follows the logical expectation based on what types of systems and infrastructure these technology products focus on. 

A WAF focuses on the following technologies:

WAF Standards

• Web 2.0, HTML, XML, JSON, AJAX

WAF Protocols

• HTTP, HTTPS
• SSL / TLS

XML Gateway technology needs to have a much more comprehensive set of technology standards and formats it supports since it is an inline deployment which requires the need to bridge technology protocols and messaging standards in order to be the "gateway" conduit of message flow. 

XML Gateway Standards

• XHTML, XML, SOAP,  JSON, AS2, XML-Sec, WS-Sec, WSDL, XSD,
• ebXML, SAML, OAuth, WS-Federation, WS-Trust, XACML
• WS-Addressing, WS-RM, WS-Policy, Xpath, XSLT

XML Gateway Protocols

•     HTTP, HTTPS
•     SSL / TLS
•     JMS (IBM, Tibco, JBoss, Oracle, Active MQ)
•     AMQP
•     FTP/FTPS
•     SFTP
•     SMTP

Security
As WAF and XML Gateway products are both security products by trade, there are 3 primary areas of Security that these technology target.

1. Threat Mitigation
2. Transaction Privacy
3. Transaction Integrity

Security: Threat Mitigation
Threat mitigation is the ability to identify, detect, and re-mediate potential threat vectors in the traffic patterns.

A WAF product mostly focuses on HTML and HTTP based traffic paradigms whereby vendor specific static vulnerability patterns can be detected, as well as other aspects of request/response patterns pertaining to HTTP traffic flow.  The primary vectors for threat mitigation for WAF technology:

• HTML Content Aware
• Intrusion Detection and Prevention (URI patterns)
• URI rate-based heuristics
• Vendor Vulnerabilities
• URL cloaking / rewrite
• Parameter Inspection
• Learning mode (false positive / false negative behavior modeling)

  An XML Gateway performs deep-content inspection and parsing of the messages at the application layer of the message pattern.  Since an XML Gateway is a protocol-break intermediary, it consumes the message, inspects the contents, and then re-assembles for sending to the back-end service infrastructure.  This puts a much higher technology burden on XML Gateway technology to understand and be able to parse a much broader variety of protocols and message formats as well as ensure adherence to industry messaging standards and formats.

The primary vectors for threat mitigation for XML Gateway technology are:

• XML/SOAP/REST Content Aware
• Intrusion Detection and Prevention (parsing and deep-inspection)
• Rate-based, Size-Based heuristics
• Schema Validation
• Virus detection on XML/SOAP payloads
• URL cloaking / rewrite
• XML Parser Attacks

Security: Transaction Integrity
Threat integrity is the ability to ensure conformance can be verified and tampering has not occurred.

A WAF will target the transaction integrity as it pertains to cookies, jsp files, RFC conformance, and other aspects of HTTP and HTML request/response expectations.  The transaction integrity targets of a WAF are:

• Session Tracking
• Cookies, Source/Dest IPs
• HTTP RFC conformance
• HTML Form parameter checking
• Cross-Site Scripting
• Cookie Signing

An XML Gateway deals with more aspects of transaction integrity since it also has to be able to handle cryptography at the message level and be able to process and verify digital signatures and provide conformance checks across a broader spectrum of formats.

XML Gateway transaction integrity features include:

• XML-DSIG, OASIS WS-Security
• Signature Verification
• X509 Path Validation
• DTD Schema Validation
• XSD Schema Validation
• JSON Schema Validation
• HTTP RFC Conformance
• JMS Envelope and Message Conformance

Identity
Identity and Access Control are central requirements for any service-based architecture with consumers and services.  It is also essential for portals and other access to information that may be sensitive or controlled.  WAF technology generally does not deal with identity, but does have some lightweight features in this area. 

The core differences between a WAF and an XML Gateway in this area are broad.  A WAF does not have awareness of many of the identity token formats outside of traditional web and HTTP based formats.

WAF: Native Identity Integrations
    Active Directory, LDAP, RADIUS

WAF: Protocol Tokens
    Basic, Digest, Form Post, SSL X509, NTLM, Kerberos


XML Gateway technology conversely, is heavily dedicated to identity token consumption, generation, authentication, and authorization.  By necessity of the deployment and flow control paradigm of XML Gateway technology, the protocol break interception for security and mediation also becomes the logical point of centralizing the identity enforcement and single-sign on functionality.


XML Gateway: Identity Integrations
   Active Directory, LDAP, Siteminder, Tivoli AM, ClearTrust, Kerberos KDC, CoreID,
   JSAM, WS-Trust, XACML, OAuth

XML Gateway: Message-Based Tokens
     WS-Username, WS-Kerberos, WS-X509, SAML, DSIG

XML Gateway: Protocol Tokens
    Basic, Digest, Form Post,  Cookie, SSL     X509, REST URI, NTLM, Kerberos

XML Gateway: Credential Translation
    Message-to-Protocol, Protocol-to-Message

XML Gateway: SSO + Federation
    Sessions, SAML, STS


Processing, Mediation, and Workflow
An area of stark difference between an XML Gateway and a WAF is in the arena of mediation, transaction manipulation, and workflow routing.  This is again a primary difference due to the topology and deployment paradigms.  Deploying a WAF in passive mode (over 50% of deployments) does not have any ability to manipulate or alter the traffic data.   For the small percentage of WAF deployments that are in-line, the types of traffic that can be manipulated are effectively the HTML variants.

XML Gateway technology is designed specifically to consume the message, parse the message, apply mediation, enrichment, transformations, and finally determine the end-point target based on static or dynamic criteria.  Thus, the XML Gateway technology component is often used to perform a wide variety of business functions outside of pure security processing.

For WAF technology, when deployed in in-line mode, the processing and mediation that can be enforced focuses on the following areas:

WAF: Workflow Management

• Allow/Deny
• URL Rewrite
• Compression
• Content Replacement

For XML Gateway technology (always deployed in-line), the processing and mediation that can be enforced goes across a wide diversity of application payload formats and protocol variants across the following areas:

XML Gateway: Workflow Management

• Attribute Mapping
• Archiving
• Content-Based Routing                  
• Database Mapping
• Digital Signatures
• Header and Body Identification
• Identity Token Conversion
• Enrichment Data Aggregation
• Encryption
• Node Conversion and Encoding
• Transformation

Complimentary, not Competitive
A robust, resilient, secure architecture starts by ensuring the right technology components are in place.  WAF technology serves an essential role in the threat and access control side of web application traffic flows.  XML Gateway technology serves an essential role in the security, identity, governance, and mediation of business services, mobile devices, B2B flows, XML, SOAP, and REST messaging patterns with deep-content inspection and business-logic mediation.   A WAF and an XML Gateway are fundamental components of a secure, centralized architecture strategy.  These technology components focus on the TCP Layer 4-7 aspects of transaction, which comprise a much broader spectrum of the actual information flow across the corporate boundaries.

These components should be deployed where traditional Protocol Firewalls and IDS (Intrusion Detection Systems) are deployed, which provide the TCP Layer 2-3 protection.

Bottom line:
WAF + XML Gateway = Secure Architecture

XML Security Gateway plugging holes for Public Clouds

Recently, there has been a flurry of news emanating from the XML security world related to researchers demonstrating an attack on Amazon's AWS cloud management interface. The attack takes advantage of a well known exploit known as XML signature wrapping or XML signature manipulation.

Amazon since the publication of this paper has plugged the security hole in its interface. It is a labor intensive effort to plug these holes that requires constant monitoring especially when cloud service interfaces are public facing. Risk can be more easily mitigated by a deployment of an XML security gateway without requiring custom code changes.

An XML security gateway prevents exploit like these in several ways. The XML gateway primary defense against this type of signature manipulation is via signed element verification. In the Amazon scenario, an XML gateway would verify that the soap:Body and wsu:Timestamp elements were processed during signature verification. A secure XML gateway verifies by checking the actual elements, not the Id attributes. This type of secure verification is the default behavior for XML gateways such as Forum Sentry.

XML security gateway's WSDL validation would also prevent the duplicate soap:Body and wsu:Timestamp elements used in this exploit. Such schema validation is important, but it is not a substitute for signed element verification, because there are alternate places to hide arbitrary content in most schema.

Amazon mistakenly assumed that ID attributes mapped to only one element without enforcing the ID uniqueness constraint. When Amazon verified that the soap:Body and wsu:Timestamp were signed, they only checked whether a matching ID was referenced in a signature, not whether signature verification actually processed all the intended elements, a subtle but important distinction. Amazon's use of signed ID verification instead of signed element verification could also allow additional exploits not mentioned here. Amazon also neglected to check for multiple soap:Body and wsu:Timestamp elements, but that is a lesser security flaw. These flaws could be the result of a misguided attempt to optimize performance by inspecting only initial portions of the document during certain security processing phases.

This specific signature exploit and other critical flaws are well-known and common in do-it-yourself security implementations, so it's essential for companies like Amazon to leverage proven security solutions and partners. These exploits indicate an apparent lack of gateway protection that could make Amazon a popular target for new exploits. Perhaps Amazon has already been the target of other undisclosed exploits. And just imagine how many other companies are hosting sensitive services without adequate gateway protection. Amazon and other web service providers need a viable commercial security strategy, and customers should expect real protection for their sensitive data and infrastructure.

XML Flaws are Pervasive

Finally! What companies such as Forum Systems pioneered a defensive layer for through its XML Gateway product, Forum Sentry, and Crosscheck Networks invented for identifying XML Security vulnerabilities thorough its XML/SOAP pen testing product, SOAPSonar is now becoming mainstream.

Washington Post published an interesting article highlighting such XML-based vulnerabilities in a recent article titled XML Flaws are pervasive. This article highlights issues that Forum Systems introduced in early 2004. See white paper titled "Anatomy of a Web Services Attack." This paper cements Forum Systems as the pioneer in identifying a new class of security vulnerabilities exposed via XML/SOAP/WSDL-based technologies.

http://voices.washingtonpost.com/securityfix/2009/08/researchers_xml_security_flaw.html

Why is an XML Gateway a requirement?

The main two reasons to justify the capital expense of an XML Gateway are performance and security. When the enterprise deems those two reasons relevant it is a no-brainer to make the XML gateway a requirement.

Now let's take a simpler scenario where performance is not a problem and security is meant to be accomplished using SSL. I claim even in this scenario purchasing a dedicated server is a wise investment. Let's assume you intent to invoke web services from multiple partners. The number of partners could potentially be on the thousands. As is the case, currently most of this partners do not have any web services as of yet. So they start as usual writing it from scratch using something like .NET. These projects tend to be low key and usually prototypes, so the use of a gateway is not even considered.

Most scenarios, in addition to using SSL mutual auth to secure the connection and authenticate the client will use some sort of XML security such as signature verification. This will require the developer coding the business case to write the required code for the signature verification. This is no trivial task to get done correctly. Even with all the help the .NET framework gives you, there are many caveats the developer will have to be aware and most likely will not have time to properly code for. I see several problems with this approach:

• The security of the deployment solely relies on the time and expertise of the developer writing the security piece. In most cases, verifying the signature is just a small piece of the puzzle, quite irrelevant to the business case. It is a necessary evil that needs to be done, but does nothing for the bottom line of the company.
• Debugging the signature verification code is time consuming. Why bother re inventing the wheel when they are companies that specialize in doing this sort of thing?
• The private keys are most likely sitting on the hard disk not properly secured. Whenever a new web services comes online the procedure will have to be repeated. This model is not scalable and at the end not cost effective.

Such use cases can be readily handled with an XML Gateway fronting all the security aspects: SSL termination, signature verification or any other security requirement. The XML Gateway centralizes all security aspects so that your developers can concentrate on the business case at hand. You can rely that your web service is properly secured without having to trust the individual ability of each developer. After all, the gateway is backed by a company so their reputation is always on the line. Private keys and certificates are on a central secured location not spread around in web servers around your organization. The Gateways are kept up-to-date with the security standards, no need to go back to every one of your coded applications to update the security aspects of it. At the end, you will have save money and time for your company and ensured the Web Service deployment is secured.

XML Gateways: Reducing the inherent Cost of Security

Dennis Sosnoski, Consultant and Trainer, Sosnoski Software Solutions, Inc. published an informative article titled: "Java Web Services: The high-cost of (WS-) Security." In the article Dennis compares performance profiles of different security configuration including SSL, username, signatures, encryption and sign-encryption. The tests are conducted using Axis2 version 1.5 with a Rampart code that provides content-level security.

The data clearly shows the overhead associated with security operations. Dennis later describes part of the reasons for the drop in performance is owed to the "Rampart handler implementation, which causes it to convert each request and response message to Document Object Model (DOM) form any time Rampart is engaged." This fact highlights one of the classic reasons for deploying XML Gateways (such as Forum Sentry): specialized commercial parsers designed for performance and security are better suited for security functions compared to java containers with general purpose parsers. Forum Sentry, as an example, has a ground-up parser designed for on-demand intelligent parsing of SOAP and XML messages without any redundant parsing. The security operations are deeply integrated with hardware cryptography. Based on almost a decade of customer installation, we have seen a 16-to-1 ratio between application servers and XML Gateway latency.

Dennis poignantly states:

"Another way of cutting the performance cost of WS-Security is to offload the security processing onto specialized hardware. Some XML gateway appliances provide accelerated processing of WS-Security encryption and signatures. You can use these appliances to handle the heavy-duty WS-Security processing while working with plain SOAP in your application. You obviously need to make sure you don't open any potential security holes in adding an appliance to your server. And you should test the performance gains from the appliance before you purchase. But at least in theory, this type of arrangement can offer some real performance gains."