The features described here complement the protection and mitigation techniques in section 3. They differ from those techniques in that they are designed as generic protection mechanisms, rather than working against specific attacks.
Hardened browser and Data Leakage Prevention (clientside): Hardened browsers can be used to reduce browser vulnerability problems. Such browsers can also be configured for finely-grained control of a user's options - like saving documents, printing, creating screen-shots, etc. A convenient way is to deliver software-based hardened browsers to each user. Another possibility is to provide users hardened browsers for example on a protected USB stick. Of course it will not be feasable to deliver hardened browsers for each and any operating system - so there is the need for defining exceptions.
- Can the use of a hardened browsers be enforced
- If yes, how are exceptions managed?
- If yes, can the export of data out of the browser be limited/prohibited?
- Is there a functionality to deploy software-based hardened browsers?
Additional protocols: Web applications may make use of additional HTTP-based protocols, such as SOAP, for direct machine-to-machine communication. This also includes communication between a client-side JavaScript program and the application server. Non-HTTP-based protocols, such as FTP for example, may also be supported by a WAF.
- Which additional protocols can the WAF ensure?
- Is there a security benefit in passing those protocols through the WAF - or are they just passed "as is"?
Additional data formats: Besides HTML, a WAF may support other data types, for instance XML, AMF or JSON. These structured data types allow for validation against a predefined schema on top of regular filtering. If a WAF doesn't recognize a data format it normally passes the data unchecked for compatibility reasons. So a WAF normally can pass all data formats - but the question is for what formats does the WAF generate an added value?
- What additional data formats does the WAF recognize and filter correctly?
EH: Ryan: this part is potentially moved into the core document (start)
Authentication enforcement (upstream authentication, delegated authentication) and Session Handling: Restricting access to web application servers to authenticated and authorized users is one of the most powerful ways to prevent attacks on such servers. The standard scenario is that the WAF performs user authentication and authorization on behalf of the protected applications. Once a user's identity is established and his or her authorization determined, access to applications is granted. If supported, ticket mechanisms like Kerberos or SAML are used, otherwise the WAF performs a login on behalf of the actual user.
- Does the WAF allow to enforce upstream authentication
- What authentication techniques are supported by the WAF natively? (password, SMS, hardware token, client certificates, ...)
- Can an already existing web-application be used to authenticate users?
- Does the WAF replace a (potentially weak) back-end session handling by a secure session?
- What types of session handling does the WAF offer?
EH: Should the SSO part be placed here? pro: a lot of common features/questions - con: SSO is not a security feature, but authentication enforcement is
Session hijacking detection: Techniques to detect attacks where the attacker takes over the victim's current session, and subsequently performs actions within the application on behalf of the victim. Such attacks can be detected by creating and constantly verifying a profile of a user's session, allowing mitigation activities like terminating session, blocking traffic, marking sessions for manual verification, or diversion to an alternative system like a honey-pot.
- Does the WAF include techniques to detect hijacked sessions?
- What aspects of a client/session behaviour can be regarded?
- Describe the offered countermeasures
Data leakage prevention (serverside): WAFs can be used to control the information which is exposed through web applications, by filtering or modifying responses before they are sent to a user (for example prevent credit card numbers to be displayed as plaintext). The same is true for information embedded in URLs (for example account numbers stored in browsing history).
- Is there a functionality to remove sensitive data from responses?
- Can information in the URL be removed/hidden?
Error message hiding: Error messages might include sensitive information (stacktraces, sql error messages, ...). This functionality is related to data leakage prevention - used to prevent an attacker from gaining insights into an application by provoking and evaluating error messages. Through response modification techniques, such error messages can be suppressed.
- Does the WAF offer a funtionality to hide/remove error messages?
Cookie protection: Cookies can be protected from tampering and/or information theft. One method to achieve this is through encryption: A WAF can encrypt all outbound cookies, so that cookies on the client are not readable by anybody but the WAF. Cookies sent along with a request are then decrypted before passing them on to the application. Even more protection can be achieved by storing cookies in the WAF. This ensures that the information is never available on the client side, and that it also cannot be omitted from the client's requests. For specific use cases (e.g. choosen user language) have to be permantently stored on the client (-> encryption). Exceptions are essential when concrete cookie values are used or generated on the client side. Cookie signing might be useful if a cookie value is used clientside (but not altered).
- Does the WAF offer cookie encryption?
- Does the WAF offer a cookie store?
- Does the WAF offer cookie signing?
Contextual HTML form protection (form validation) and upstream data type check: HTML forms play a central role in several different attacks, mainly injection and cross site scripting attacks. A protection can be achieved, for instance, by using the information contained in a HTML form definition as a specification, against which user input is then validated. This also allows to ensure that static form elements like drop-down menu content and radio button values are not tampered with. Especially HTML5 allows more type information in forms (url, email, datetime, pattern restrictions, ...). As an advanced technique, an application could even communicate further information regarding permitted field values (-> upstream data type check). This allows application programmers to influence the WAF's behavior without actually having to change the WAF's configuration. The benefit of this dynamic approach comparing to static rules is that variable conditions (daytime, account balance, content of shopping cart, ...) can be checked as well.
- Are informations in HTML forms dynamically used to generate request inspections?
- Is there a possibility for back-end applications to provide further dynamic information about allowed values (upstream data type check, ranges, ...)? What are those possibilities?
Security headers: Modern browsers support a variety of security features controlled by HTTP response headers (Strict transport security, Frame Options, XSS-Protection, Content security policy, ...).
- Does the WAF set/control security headers? What headers?
Workflow binding: Most web applications rely on workflows. What happens if a user directly accesses the "print ticket" step without having ordered anything? Those URLs can be guessed or bookmarked by a user for later re-use. An application's workflow can easily be circumvented this way. This may lead to erroneous behavior, or give an unauthorized person access to protected information. Workflow binding prevents this by ensuring that each page call can only be performed in the context of a correctly followed workflow. An important characteristic for this functionality is the ease with which exceptions and entry URLs can be defined.
- Is it possible to restrict the currently allowed URLs to a defined set? How is this achieved?
- How are exceptions handled? (Bookmarking, search engine result clicks, direct deep linking from other pages, ...)
Forceful browsing protection: Related to workflow binding: Users and potential attackers should be prevented from accessing resources outside what is presented to them through the regular application pages. These may be files that were never intended to be accessed through a browser.
- Does the WAF prevent random file access? How is this achieved?
- Has the WAF the ability to detect tampered URLs / requests?
Architecture masking: Often, internals of a system's architecture should not be exposed to outside users. WAFs, through their response modification capabilities, can for example re-write outgoing content to mask the actual architecture details. By rewriting the path it is not only possible to hide internal implementation details but also to get a more user oriented URL showing the current "place" or "step". There is no need for users/attackers to know the concrete implementation details such as application server, framework or language. Not even a knowledge about what services are implemented on the same or different servers is needed.
- Ability to hide/change the "Server:" header
- Ability to change the concrete URL path from a technical internal view to a service-oriented client view
- Ability to change or hide framework and server information - such as session cookie names, specific http headers, file extensions, ... . Describe the measurements the WAF takes for achieving this.
- Possibility to allow a single virtual host to have multiple different back-end servers serving different content
EH: end of the part to be potentially moved
As central components within a DMZ, WAFs are in a unique position to provide network architects with additional functionality which otherwise often has to be specifically brought in.
Load balancing and health checks: A WAF can act as a load balancer, and distribute incoming requests over several identical application servers, following certain rules such as session stickiness (a user is served by the same server for all of his requests). This can be further enhanced by in-band (using the normal user requests) or out-of-band health checks (using time controlled extra requests produced by the WAF), which provide information on each application server's availability.
- Which load balancing methods are available? (round robin, weighted, spare, starving, best available)
- Which health checks are available? (ping, HTTP query, custom HTTP query, passive in-band checks)
Performance optimization: In addition to load-balancing, a WAF can improve a web application also by compressing the output, as well as by caching frequently-requested resources and other mechanisms.
Does the WAF offer
- Compression
- Connection pooling for back-end requests
- Caching
- TCP optimizations
- keep alive settings
- offloading static content to be delivered by the WAF itself
- other mechanisms for performance optimization?
- A user might or might not have to see content that was cached in another users context. How is it guaranteed, that caching is done in a safe and efficient way?
Traffic Shaping: According to the business case some requests, users, networks or applications shall be priorised against others. Delaying some or all traffic packets is a possibility to target a desired traffic profile, it is used to optimize or guarantee performance or to mitigate flash crowd events (and some kind of denial of service attacks).
- Does the WAF offer traffic shaping?
- On which parameters traffic class can be defined?
SSL management: The handling of SSL certificates and keys can be hard if the certficates are spread across many servers. The security of a private key decreases potentially with each installation of the key (since the administration interface might not be well protected). SSL management can be centralized in a WAF, rather than having each application handle SSL itself. The WAF can be the SSL end-point, performing SSL termination, and also manage all SSL certificates. Valuable keys can be administered on one server rather than on many.
- Does the WAF offer a centralised SSL certificate and key handling?
- Can the WAF check client certificates?
- How are certificate revocation lists handled?
- Which SSL ciphers are supported?
Protocol translation: The need for replacing one protocoll by another can emerge at various layers of the OSI model. Widespread use cases are the translation of unencrypted internal HTTP services to be external HTTPS - or enable old school IPv4-only applications to be accessible by IPv6.
- Ability to translate external IPv6 to internal IPv4
- Ability to translate internal HTTP to external HTTPS
Single sign-on: SSO allows the access to multiple (web) applications with only one log in action needed. Since they concentrate all web traffic for several applications, WAFs with upstream authentication capabilities can provide single sign-on functionality across all those applications. In this case, some form of log-out propagation across all the authorized applications is required, along with a well though-out time-out handling.
- Does the WAF have a single sign-on functionality?
- What back-end authentication mechanisms are supported? (Basic Auth, Form based login, Kerberos, SAML, ...)
- Does the WAF integrate with access managment suites? If yes, with which?
- Is there a logout propagation functionality for back-end applications?
- What types of session timeouts does the WAF handle/check (idle time, session lifetime, timeouts per application, ...)?
IP reputation: IP reputation databases can help to identify various attack sources even before the HTTP request has been sent.
- Does the WAF offer IP reputation service?
- Which categories the reputation feed includes?
To increase their versatility, WAFs often offer multiple extension mechanisms.
Back-end API: Allows web application programmers to make use of a WAF's functionality, like authentication, or to control a WAF directly from a protected web application. One concrete example would be additional information in response HTML, to control the filtering of HTML-form values (see Contextual Form Protection). Other use-cases are mechanisms to propagate authentication, authorisation and logout - or the information sharing across different back-end applications.
- Is there a documented API for web application to take benefit of WAF funtionality?
- If yes, does the WAF offer all crucial information about the request such as: original IP, client certificate data, unique request ID (for combining events across various logs) and session ID, original protocol and original server name (virtual host)?
- If yes, what actions/behaviour can be triggered through this API?
Administration API: Allows WAF administrators to automate the WAF's operation, or to increase the WAF's protection capabilities. One example would be an API and corresponding SDK for additional, customized filters.
- Is there an API/SDK for implementing customized functions such as filtering or rewriting?
- What programming languages are supported to write customized code?
ICAP and offloading: In some scenarios, it is desired to offload functionality to external services. ICAP is a protocol related to HTTP, which was specifically designed to allow connecting external services to a reverse proxy or WAF. An ICAP server receives client requests or server responses from the WAF, and can then reject, modify or pass them on. Examples for ICAP servers are malware scanners, customized filter engines, or any service that requires being supplied with the data traffic between client and application server.
- Does the WAF have an ICAP interface?
- Is there another possibility to offload functionality?
Intellectual property:
- What, if any, protection exists for the intellectual property used within the WAF?
- Is it open source?
Certification:
- What certifications does the WAF have?
Updates:
- How many product updates are to be expected per year?
- In what form are they notified, delivered, installed?
- Is there a distinction between feature/functionality updates and security updates?
- Are security updates rated for their importance/urgency/impact?
- Are updates protected from tampering?
- What is the impact of an update installation on the WAF's and its protected applications' availability to end users?
- Are updates reversible? Describe the steps for uninstalling them.
Upgrades:
- How can the WAF be upgraded to growing sizing requirements (number of applications, amount of traffic, etc.)?
- Describe the upgrade steps to ensure minimal downtime
- Is an upgrade possible without downtime?
- If not, what is the minimal downtime?
- Are upgrades/updates possible without session loss?
Vulnerability reporting:
- Are vulnerabilities of the WAF and/or of applications protected by the WAF reported?
- Publicly, or to a closed user group?
- Are recommendations supplied on how to mitigate those vulnerabilities?
- According to OSVDB what is the mean patching time for a WAF vulnerability?
Pricing and licensing model:
- What factors determine the price of an installation?
- What does a customer actually get for the purchase price?
- Are software licenses limited in duration or are they perpetual?
- Are all updates included in the license fee, or do they incur additional cost?
Warranty:
- Does the WAF vendor give any warranties regarding the security provided by his product?
Community:
- Is there a community of users of that particular WAF?
- Forum, user group, mailing list, web site?
3rd party vendors:
- What 3rd party vendor or developers offer add-on modules to the product?
Knowledge database:
- Does the vendor provide technical insights through a web repository of issues and their solutions?
- Is it public, or only available to a closed user group?
- How many public knowledge base articles are available?
References:
- Who is using this WAF?
- What types of applications are being protected by it?
- Are reference cases provided, are reference customers available for direct contact?
Team size:
- How many developers work exclusively on the WAF's development?
User feature requests:
- How does the product team deal with customer input?
- Is there a defined process for feature requests and improvements?
- Is a product roadmap available?
Support:
- What support time models are available?
- Pricing model for support?
- How can support be reached (email, phone, portal, other)?
- Guaranteed support reaction time? (in hours)
- Minimal RMA shipment service? (in hours)
- Which timezones are covered by support?
- What languages are covered by support?
References:
- What companies, from what markets (geographical, industry) are using products from that company?
- What is the reputation of the company?
- Does the company hold any certifications?
Target market:
- What are the company's target markets, geographical and by industry?
- What market penetration do they achieve?
Company details:
- How big is the company?
- Where is it located?
- Financial stability: describe the financial state of the company (last year revenue, profit, operating margins, depts)
Partner:
- If the product is sold by partners then the "Company criterias" might be applied to them as well.