Version 1.0 (January 16, 2006)
Copyright © 2005,2006 Web Application Security Consortium (http://www.webappsec.org)
Table of Contents
Web Application Firewalls (WAF) represent a new breed of information security technology that is designed to protect web sites (web applications) from attack. WAF solutions are capable of preventing attacks that network firewalls and intrusion detection systems can't. They also do not require modification of the application source code. As today's web application attacks expand and their relative level of sophistication increases, it is vitally important to develop a standardised criteria for product evaluation. How else can we accurately compare or measure the performance of a particular solution?
The goal of this project is to develop a set of web application firewall evaluation criteria; a testing methodology that can be used by any reasonably skilled technician to independently assess the quality of a WAF solution. However, our aim is not to document the features that must be supported in order for a product to be called a web application firewall. Web application firewalls are simply too complex to be treated like this.
To conclude: the purpose of this document to draw one's attention to the features that are of potential importance to a given project. This comprehensive list should be used as basis to form a much shorter list of features that are required for the project. The shorter list should then be used to evaluate multiple web application firewall products.
Current categories are as follows:
Deployment Architecture
HTTP Support
Detection Techniques
Protection Techniques
Logging
Reporting
Management
Performance
XML
We expect to cover the following categories in the subsequent releases:
Compliance, certifications, and interoperability.
Increase coverage of performance issues (especially on the network level).
Increase coverage of the XML-related functionality.
This document is a result of team effort. The following people have contributed their time and expertise to the project:
Robert Auger (SPI Dynamics)
Ryan C. Barnett (EDS)
Charlie Cano (F5)
Anton Chuvakin (netForensics)
Matthieu Estrade (Bee Ware)
Sagar Golla (Secureprise)
Jeremiah Grossman (WhiteHat Security)
Achim Hoffmann (Individual)
Amit Klein (Individual)
Mark Kraynak (Imperva)
Vidyaranya Maddi (Cisco Systems)
Ofer Maor (Hacktics)
Cyrill Osterwalder (Seclutions AG)
Sylvain Maret (e-Xpert Solutions)
Gunnar Peterson (Arctec Group)
Pradeep Pillai (Cisco Systems)
Kurt R. Roemer (NetContinuum)
Kenneth Salchow (F5)
Rafael San Miguel (daVinci Consulting)
Greg Smith (Citrix Systems)
David Movshovitz (F5)
Ivan Ristic (Thinking Stone) [Project Leader]
Ory Segal (Watchfire)
Ofer Shezaf (Breach Security)
Andrew Stern (F5)
Bob Walder (NSS Group)
Participation in the Web Application Firewall Evaluation Criteria
project is open to all. If you wish to comment on the evaluation
criteria or join the team mailing list please contact Ivan Ristic via
email (<ivanr@webkreator.com>).
This section highlights the questions key to determining the feasibility of web application firewall deployment in a given environment.
Can the device be operated in both passive and active (inline) mode?
Describe which of the following active modes of operation apply to the WAF:
Bridge. Can be installed as a transparent bridge. Can it be configured to fail open?
Router. Network must be reconfigured to direct traffic through the WAF.
Reverse Proxy. Traffic is re-directed to flow through the WAF by making changes to DNS configuration or by traffic redirection on the network level.
Embedded. WAF is installed as a web server plug-in. Which web servers are supported? Explain the level of integration with the web server. Some embedded web application firewalls may only tap into the communication channel and do everything themselves. Others may rely on the web server to do as much of the work as possible. (Both approaches have their advantages and disadvantages.)
SSL is often used to protect traffic coming from and going to web applications. While this type of protection achieves the goal of data protection, it hides the data from the protection systems (e.g. intrusion detection systems, web application firewalls) at the same time. Since SSL is in widespread use - in fact, secure deployments require it - if a WAF cannot get to the traffic then it will be unable to perform its function.
Describe how the WAF can be deployed to access the protected data:
Terminates SSL. The network needs to be re-configured to move the SSL operations to the WAF itself. WAF decrypts the encrypted traffic to get access to the HTTP data. The communication between the WAF and the web server can be in plain-text, or SSL-encrypted.
Passively decrypts SSL. Configured with a copy of the web server's SSL private key WAF decrypts the SSL traffic. The original data stream travels unaffected to the web servers, where it is separately decrypted and processed.
Not Applicable. Working embedded in a web server, a WAF can be positioned to work just after the SSL data is decrypted into plain-text.
Client certificates criteria:
Are client certificates supported in passive mode?
Are client certificates supported in active mode?
In termination mode, can the content from client certificates be sent to the application using some alternative transport method (e.g. request headers).
Other SSL criteria:
In termination mode, can the backend traffic (i.e. the traffic from the WAF to the web server) be encrypted via SSL?
Does the WAF support client certificates for backend communication?
Are all major cipher suites supported by the SSL implementation. Which ones?
Can the WAF retrieve SSL keys from an external key storage facility (e.g. network-based Hardware Security Module)?
Is the SSL implementation FIPS 140-2 certified? Which FIPS levels are supported (level II and/or III)?
Is there support for hardware-based SSL acceleration? If there is, are the SSL certificates securely stored in the hardware?
If the WAF is capable of blocking offending traffic, describe the nature of the blocking functionality:
Connection Intermediation. Traffic is intercepted and network protocol connections are terminated on the WAF. Attacks are blocked by not forwarding the blocked requests to the destination.
Connection Interruption. Traffic is inspected, but not terminated by the WAF. Attacks are blocked by stopping the connection to the destination. This can be either before any packets arrive at the destination (e.g. a single-packet attack), or after a partial connection has been buffered, but not completed, on the destination (e.g. in the case of segmented packets).
Connection Reset. Traffic is inspected by the WAF either via active, passive or embedded inspection mechanism. Attacks are blocked by resetting the relevant network (TCP) connections. Connection reset is often used in conjunction with other blocking mechanisms.
Blocking via third-party device. Traffic is inspected by the WAF. Attacks are blocked by notifying other devices (e.g. router or network firewall) to block a connection.
Describe the scope of blocking capabilities:
Blocks the HTTP request.
Blocks the connection.
Blocks the IP address.
Blocks the application session.
Blocks the application user.
When blocking is taking place on the HTTP level, can the WAF be configured to present the user with a friendly, meaningful, message? Can a unique transaction ID be presented to the user (see Section 5.1)?
For a WAF that supports blocking, is it possible to turn blocking off (completely, or for certain types of requests only - determined dynamically for every request)?
Describe how WAF is delivered:
Appliance. Software bundled with hardware. Appliances are usually highly optimised and may contain specialised hardware components to increase performance. Are there other optional hardware components that may further increase performance (except for SSL, which was already covered in 1.2)?
Software only. WAF is delivered as software application that can be installed on a generic computer. Describe the reference hardware configuration. Is the application delivered integrated with an operating system? Or does it require an operating system to be installed on? Which operating systems are supported (including versions)? Are there other optional hardware components that can increase performance further (such as SSL encryption cards)?
There are two aspects of the high availability requirement. One is to prevent the web application firewall from becoming a single point of failure. The other, to allow the WAF to scale and remain fully functional for very busy sites. The questions are as follows:
When used in active mode, is it possible to configure the WAF to fail open?
Does the WAF support multi-node operation? Describe possible architectures.
In a two-node high availability system, how does the unit fail over, and in what timeframe?
In a two-node high availability system, can the second node share the load?
Is the node state shared? (If the state is shared then a node can go down without any impact on the system.) Specifically, does the stateful nature apply to SSL sessions?
Can multiple WAF nodes be configured to work in a cluster (of more than two nodes)? What is the maximum number of nodes supported?
Can nodes be geographically distributed across data centres? How does this affect failover and state?
Does the WAF support complete virtualisation of the external application representation? Describe the support for virtualisation:
Virtual hosts.
Network ports.
URL mappings.
Authentication realms. (Covered in more detail in Section 2.7.)
Cookies.
Sessions.
Does the WAF support HTML (response) rewriting to change URIs after virtualisation takes place?
Is access to the HTML rewriting functionality given to the user? Which parts of the traffic can be rewritten?
Request headers.
Response headers.
Parameters (including those in
QUERY_STRING,application/x-www-form-urlencodedPOSTrequests, andmultipart/form-dataPOSTrequests.Request body - raw.
Request body - XML.
Request body - other (list supported content types).
Response body - raw.
Response body - HTML.
Response body - other (list supported content types).
Is there support for caching?
Is there support for transparent response compression?
Can the WAF completely rebuild back-end requests?
The following encoding types should be supported:
Supports
application/x-www-form-urlencodedencodingSupports
multipart/form-dataencodingSupports v0 cookies
Supports v1 cookies
Supports chunked encoding in requests
Supports chunked encoding in responses
Supports request compression
Supports response compression
Can restrict methods used
Can restrict protocols and protocol versions used
Strict (per-RFC) request validation
Validate URL-encoded characters
Validation of the non-standard
%uXXYYencodingCan enforce cookie types used (e.g. only allow v1 cookies)
Which of the following restriction methods are supported:
Element content.
Element length.
Element byte range.
Character set validation (e.g. UTF-8). Which character sets are supported?
How flexible is the WAF when it comes to applying different restriction policies to different parts of the request? Can restrictions be set at the application level, the object level, and/or the parameter level?
The following protocol limits should be supported:
Can restrict request method length
Can restrict request line length
Can restrict request URI length
Can restrict query string length
Can restrict protocol (name and version) length
Can restrict the number of headers
Can restrict header name length
Can restrict header value length
Can restrict request body length
Can restrict cookie name length
Can restrict cookie value length
Can restrict the number of cookies
Can restrict parameter name length
Can restrict parameter value length
Can restrict the number of parameters
Can restrict combined parameter length (names and values together)
Support for
POSTfile uploads (multipart/form-dataencoding)Support for
PUTfile uploadsIndividual file size can be restricted
Combined file size can be restricted
The number of files in a request can be restricted
Is it possible to add custom logic to inspect uploaded files?
Web Application Firewall must evaluate request data in the character encoding used by the application in order to provide adequate protection.
This section covers support for standard or widely deployed authentication methods. The supports needs to be evaluated from two points of view.
Can WAF support applications that use these authentication methods?
Basic Authentication
Digest Authentication
NTLM Authentication
Client SSL certificates
Can WAF support these authentication methods directly (i.e. providing an additional authentication layer)?
Basic Authentication
Digest Authentication
NTLM Authentication
Client SSL certificates
Two-factor authentication
Note
More details on support for SSL client certificates are available in Section 1.2.
Can authentication be integrated with any kind of backend authentication scheme? Is there built-in support for common authentication backend types (e.g. LDAP, RADIUS, etc).
Can WAF support security assertion and Federated Identity protocols?
SAML (1.0, 1.1, 2.0)
Liberty-ID-FF (1.0, 1.1, 1.2)
WS-Trust
Web systems are often designed as a combination of many related systems. This allows the attackers to attempt evasion by transforming the attack payload into a form that appears harmless to the web application firewall. The large variety of backend systems used makes the work of WAFs very difficult. In order to make rules and signatures useful WAFs must attempt to detect evasion attempts and transform input data into a normalised form.
Does the WAF support the following normalisation methods:
URL-decoding (e.g.
%XX)Null byte string termination
Self-referencing paths (i.e. use of
/./and encoded equivalents)Path back-references (i.e. use of
/../and encoded equivalents)Mixed case
Excessive use of whitespace
Comment removal (e.g. convert
DELETE/**/FROMtoDELETE FROM)Conversion of (Windows-supported) backslash characters into forward slash characters.
Conversion of IIS-specific Unicode encoding (
%uXXYY)Decode HTML entities (e.g.
c,",ª)Escaped characters (e.g.
\t,\001,\xAA,\uAABB)
When negative security model is used transactions are allowed by default. Only those transactions that contain attacks are rejected. The success of this model depends on the WAF being able to detect bad requests.
The questions are as follows:
Signature-based. Signature-based products usually detect attacks by performing a string or a regular expression match against traffic.
Rule-based. Rules are similar to signatures but allow for a more complex logic to be formed (e.g. logical
AND, logicalOR). They also allow for specific parts of each transaction to be targeted in a rule.
Positive security model denies all transactions by default, but uses rules to allow only those transactions that are known to be valid and safe. This approach can be more efficient (fewer rules to process per transaction) and more secure, but it requires very good understanding of the applications being protected. The positive security model can also be more difficult to maintain if the web application changes frequently.
The questions in this section are as follows:
Is the positive security model supported?
Can positive security model be configured manually?
Can positive security model be configured automatically (training)? What tools are available for automatic configuration? How is the automatic configuration maintained (dynamically, manually, completely re-learn)?
Does the tool support model updates (without re-training)? Can this be done during run-time or does the WAF need to be taken offline for policy modifications?
Positive security model can be achieved using strict content-validation policies, or using statistical analysis or neural networks in an approach commonly referred to as anomaly-based detection.
Signature/rule database:
Does the product come with a database of signatures (or rules), which are designed to detect known problems and attacks.
How many products does the database support?
How often is the database updated?
Is the database cross-referenced to operating systems, applications, and versions, allowing the administrator to apply only the applicable signatures?
This section lists specific requirements for protection that are not (and cannot be) covered using generic protection mechanisms described in other sections. Describing all possible web application security classes of problem is out of scope of this document. You will find this area was already covered in the Threat Classification project: http://www.webappsec.org/projects/threat/.
Detect brute force attacks against access controls (HTTP status code
401).Detect brute force attacks (repeated requests for the same resource) against any part of the application.
Custom brute force attack detection for applications that do not return
401(probably with a regular expression applied to a response part).React by either slowing or blocking the attacker down.
Detect brute force attacks against session management (too many sessions given out to a single IP address or range).
Detect automated clients (session requests are too fast).
Sign cookies, to prevent clients from changing them.
Encrypt cookies, to hide contents.
Hide cookies altogether (cookie mechanism virtualisation: only send unique cookie IDs back to the client).
Is it possible to configure protective measures per application or otherwise control where they are applied?
Complete virtualisation of the session handling mechanism used in the application. Which transport methods are supported:
Cookies
Form parameters
URI rewriting
Can session IDs be tied in with the SSL session ID values?
Can session IDs be tied in to the authentication mechanism?
Is it possible to configure protective measures per application or otherwise control where they are applied?
Is there a mechanism to (optionally) protect certain hidden form fields from changing?
Does the WAF support any kind of generic cryptographic URL Encryption to protect application URLs and parameters against manipulation (forceful browsing, session riding, etc.)?
Unique transaction ID is assigned to every HTTP transaction (a transaction being a request and response pair), and included with every log message.
Access logs refer to a record of all transactions that went through the WAF. Access logs are most commonly delivered as files, although other forms are also in use (e.g. databases).
Access logs can be exported as files.
Which commonly-used log formats are supported?
Access log format can be customised.
Access logs can be sent to the logging server via Syslog.
Access logs can periodically be uploaded to the logging server (e.g. via FTP, SFTP, WebDAV, or SCP).
Event logs refer to a record of all suspicious transactions. Events logs are commonly delivered as files, or are stored in a database.
We are expecting web application firewalls to support some of the following notification methods:
Email
Syslog
SNMP Trap
OPSEC Event Logging API (ELA - http://www.opsec.com/intro/sdk_overview.html#ela)
Notification via HTTP(S) push.
Periodic event log upload via one of the supported upload mechanisms (see 5.2).
It is also important to note the format in which the events are imported. Is the format:
Plain-text based?
XML-based?
Or is there an API to customise the format?
Full transaction logs must include complete HTTP requests and responses. The emphasis is on the request body, with the option to record the response body too. The requirements are as follows:
The transaction log format should be well documented.
It should be possible to configure the detail level. For example, to allow users to record request bodies but not record response bodies. A really smart tool could be configured to record limited detail on non-suspicious transactions, but to record full detail of suspicious transactions.
It should be possible to configure which transactions are logged. For example, a user may want to log only the suspicious transactions, or only the transactions that involve dynamic processing on the server.
A WAF that understands sessions could be configured to start logging full session data once a suspicious transaction is detected.
The following are requirements for log access:
Logs can be exported (as files) via FTP or SCP, periodically or on demand.
Logs can be accessed directly in the a database (either real or simulated), using an ODBC/JDBC driver. The database schema is published and documented.
Logs can be accessed via an API (pull).
API exists that allows a plugin to be developed to manipulate log entries as they arrive (push).
Can logs be digitally signed to thwart tampering?
If the tool supports Syslog then the following requirements need to be evaluated too:
Supports UDP-based Syslog logging.
Supports connection-oriented Syslog logging.
Connection-oriented Syslog logging can be wrapped in SSL to protect the logs in transport.
When SSL is used, client and server certificates can be specified for additional security.
Log retention refers to the ability of the device to preserve the important logs in accordance with the organisational policies, and to prevent the system from overflowing.
Maximum age of the logs can be specified. Logs older than the specified age are deleted.
Maximum size of the log store can be specified. Once the store reaches the maximum size the oldest logs are deleted.
There is support for multiple log retention policies (e.g. transactions involving policy violations can be kept for longer).
Logs can be automatically backed up before they are deleted.
Can the WAF remove (sanitise) sensitive data from the logs?
Is sanitation configurable (e.g. explicitly specify which parameters to obfuscate)?
Can the WAF automatically detect sensitive data? Can this feature be customised?
Which obfuscation methods are available? (One simple method is to replace every byte with a character, for example
*. Another, to use a reversable transformation, which would allow staff to decode data if necessary.)
While it is expected the analysts will review the events frequently, reports are needed to track the overall security level:
Can generate comprehensive event reports. Which filters are available:
Date or time ranges?
IP address ranges?
Types of incidents
Other (please specify).
Reports can be generated on demand.
Reports can be generated on schedule (e.g. daily, weekly)
The following report formats are deemed of relevance:
Word
RTF
HTML
PDF
XML (for further, custom, processing)
The goal of customisation is for reports to appear as most other documents produced in the organisation:
Visual customisation (e.g. colour, logo, etc).
Content customisation (target groups, e.g. Executive, Developers, etc)
Do reports contain appropriate graphs?
Which target groups are supported out-of-the-box?
Management is a key part of any network device. This is especially true for application security devices, since this layer is constantly changing to address specific needs, which are directly related with business requirements. For this reason, a WAF’s management component should meet a set of requirements that will guarantee adequate policy enforcement, refinement, and verification. Also, management should be designed and implemented carefully, so that it doesn't interfere with service components in terms of throughput or availability. The following are topics that must be covered by WAF’s management components. They are classified into several categories in order to better understand what requisite belongs to which component. Also, this approach make easier to evaluate a WAF device from a high abstraction level: components can be scored individually without delving into specific details related to them.
Most of WAF devices can automatically learn application logic and build a policy that addresses security and service requirements in that application. Nevertheless, if this policy generates too many false positives, there should be an easy procedure to selectively relax its enforcement rules, instead of having to rebuild it from scratch with lower security level.
There must be an easy way to include legitimate requests originally considered as attacks by the current security policy. This task shouldn't be harder than clicking on a log entry and pushing changes to the WAF device.
This is very self-descriptive. Newer applications probably need a learning-mode phase that shouldn't apply to the rest of applications for which a stable policy has been already built.
Also see Section 2.2.4 for more requirements for the policy granularity.
Positive Security Model should clear the need for signatures. Nevertheless, many commercial products combine both methods of detection for improved accuracy. In this case, management components should include facilities to develop custom signatures that identify specific, unique risks associated with protected applications.
There is no standard definition of what can be considered a denial of service in every environment. For this reason, WAFs must let the administrator define or refine parameters used to identify this type of attacks. Even better, the device may be smart enough to build an statistical model of what is considered legitimate use of an application and identify when a DoS is taking place, in terms of deviation from this model.
Policies must offer a high level of granularity. Switching between detection and policy enforcement (prevention) modes cannot be associated with the whole application, but must be granularly associated with every component of an application or every type of attack. This lets an administrator just monitor some potential illegal activity in the application while blocking true intrusion attempts at the same time.
If the new version of one policy fails to correctly protect the website or affects the way services are provided, there should exist one mechanism to easily roll-back to the previous applied policy.
Learning mode is based on watching traffic between clients and applications, considering that no attacks will occur over that period of time. This assumption may not be true in many cases; for this reason, there must be management configuration facilities to specify trusted hosts that will let the WAF device learn only legitimate traffic.
There must exist some built-in mechanism that lets the WAF learn application logic without the need for users to manually browse the website. This can be a spider, scanner or crawler that automatically visits every link on every page and behaves as a human user, making use of all the services in the website. The spider must be accurate enough and fully integrated with the policy editor. Also, it may be useful to schedule these scan tasks in order to quickly identify changes made to web applications and adjust the current policy accordingly.
Sometimes wizards and WAF’s intelligence is not enough to create accurate policies. For this reason, there must exist a way to delve into low-level details of policies and adjust them somehow. This can mean making changes to regular expressions or adding new ones.
There must be multiple profiles in the device user login, to support segregated responsibilities. These might include, but not be limited to: device operators (for box configuration), application owners (for policy configuration), auditors (for log inspection) and so forth.
Trusted hosts (identified by IP addresses or IP address ranges) sometimes need to be allowed to perform activities that are otherwise prohibited by policy. For example, when a penetration test is executed it is necessary to turn off the protective measures and/or prevent the detected attacks from escalating into alerts.
Can the WAF suppress prevention techniques for trusted hosts and only log the error messages as notices?
Can the WAF ignore traffic coming from trusted hosts (not even logging the notices)?
If signatures are included as an additional detection method, there should be an option to automatically download and install updates in every sensor.
It’s recommended that WAF devices communicate with management systems over a dedicated management network. This enables administrators to securely perform maintenance and configuration tasks. Also, communications between the management systems and WAF devices must be simple enough to traverse firewalls and secure enough (that is, encrypted with strong algorithms) to avoid eavesdropping or other types of attacks based on protocol analysis.
The management components must be able to monitor system status and alert the administrator when an error condition occurs or when performance is somehow impacted. Typical notification mechanisms are e-mail, SNMP, syslog and pager.
Log suppression is a simple mechanism to aggregate logs in a clever way and simplify WAF’s activity reviews: similar entries are presented as being just one, with an additional column showing how many times this entry was registered. Criteria used for joining entries are user-defined.
Statistics can help an administrator check if the WAF device is performing as expected. Also, it provides hints about the protected servers’ activity and performance. The following is basic statistical data that must be available in the ligament tool:
number of requests/connections/sessions per second
percentage of malicious requests
percentage of blocked requests (when combining detection and prevention)
number of errors over time
types of browsers identified (through User-Agent header)
most accessed URLs
This data should be available in readily-accessed logs, or even displayed on the device itself (with the recognition that advanced user behaviour reporting is not the primary function of a WAF).
Buggy interfaces are painful when dealing with WAF devices. For this reason, special care should be taken to avoid exceptions, management subsystems faults and error messages while using the UI. There must exist a mechanism to assure that if an error occurs while pushing new policies to the sensor, the WAF device will get back to its original state.
On the other side, the UI must be hardened enough to make sure that it is not vulnerable to the same types of attacks it protects of. This includes common techniques like SQL Injection or Parameter Tampering , but also advanced forms of exploitation.
Is the management interface implemented as:
Native application?
Web-based application?
Is there a separate network interface to form a separate channel for device management?
Is there a dedicated management interface? How is it implemented:
Separate network interface for SSH/HTTPS access?
Serial console access?
Is two-factor authentication supported for management access? Describe what is supported.
Does the WAF provide any kind of backend control API so that backend applications can influence the behaviour of the WAF (e.g. terminate user session, block IP, delay logon retry, etc.)?
We acknowledge the issue of performance is a complex one. Measuring the performance of a WAF on network level is especially difficult and out of scope of this document. (For one approach have a look at the methodology used by the NSS Group: http://www.nss.co.uk/WebApp/Ed1/WebApp%AD_Performance_Testing.htm) The two subsections we include here are targeted toward measuring the overhead of a WAF when no protective measures enabled. We are likely to expand this section over time.
Maximum new connections per second.
Maximum throughput per second (retrieving a single 32KB HTML page).
Maximum requests per second (with Keep-Alives enabled).
Maximum number of concurrent connections.
Request latency.
The above performance criteria assumes maximum values with no packet loss.
Performance measurement with SSL enabled (but disabled at the backend):
Maximum new (not resumed) SSL connections per second.
Maximum SSL session resumptions per second.
Maximum SSL traffic throughput with a given encryption algorithm (retrieving a single 32KB HTML page).
Maximum requests per second (with Keep-Alives enabled).
Maximum number of concurrent connections.
Request latency.
The above performance criteria assumes maximum values with no packet loss.
This section contains only the basic XML questions at the time. We expect the content to be expanded in the subsequent releases.
Does the WAF support protection of XML Web Services?
Can WS-I Basic conformance be specified (http://www.ws-i.org)?
Can the WAF restrict XML Web Services access to methods defined via Web Services Description Language (WSDL) ?
Can the WAF deny XML Web Services access to an administrator-defined set of WSDL methods?
Can the WAF restrict XML Web Services inputs to an administrator-defined set(s) of data types (parts) and formats?
Does the WAF perform validation for both Web Services RPC communications?
Does the WAF perform validation for Web Services XML Documents?
Describe additional XML Web Services functionality.
A. Licence
This work is licensed under the Creative Commons Attribution License. To view a copy of this license, visit http://creativecommons.org/licenses/by/2.5/ or send a letter to: Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
