Best Practices for Web Filters

You can use these best practices to create more efficient and secure Web filters.

Handling Data

Web filters should be designed not to allocate excessive amounts of memory per session or request so that they will not become vulnerable to a denial-of-service (DoS) attack. If filters accumulate data (for example, until a complete request is stored in memory), they should set a maximum total number of bytes that may be allocated per request. If this maximum number of bytes is significant, we also recommend that they limit the time during which a request can be stored. In more advanced Web filters, quotas should be applied.

Web filters should never trust data. They should verify that the data is coming from the correct side. For example, they should verify that the client is not sending information that should be coming only from the server. Your filter should also verify that the data has the correct format.

When using hash tables, use salt and other mechanisms to make sure that clients will not be able to craft data that will always be sent to the same bucket.

Web filters should avoid using nonlinear complexity functions when the data chunks for a process may be very large.

Blocking Operations

The Web filter API is synchronous. Therefore, Web filters should not make calls that launch lengthy blocking operations. In particular, the WriteClient and WriteServer callback functions block the thread from which they are called until the I/O operation is completed. A Web filter sending a large amount of data in a call to either of these functions can block all of the available worker threads with a resultant denial of service (DoS).

Filter Setup

If a Web filter also provides an extension for Forefront TMG Management, the setup program should allow for separate installation of the administration component and the filter component because Forefront TMG Management can be run remotely. In particular, Forefront TMG Management can be run from a remote computer on which the Forefront TMG services are not installed.

During filter registration, the error code HRESULT_FROM_WIN32(ERROR_ALREADY_EXISTS) should be considered as a success code, and installation should continue in a normal flow. This is done to avoid problems in re-registering an existing filter.

When a Web filter is being uninstalled, the filter should try to uninstall all the objects that it registered (events, alerts, etc.), even if some of them no longer exist and an error code is returned. This is done to ensure that maximum cleanup is achieved, and to ensure forward compatibility with future support for array mode.

Writing to the Stored Configuration

Web filters should not attempt to write to the stored Forefront TMG configuration. The Forefront TMG proxy is allowed read-only access to the stored Forefront TMG configuration. Therefore, a Web filter that relies on successfully writing to the stored configuration will fail.

Any changes to the stored configuration that are needed for a Web filter should be made by the setup process or through the Web filter's administrative component.

 

 

Build date: 7/12/2010