Best Practices for Creating Filter Handlers in Windows Search
Microsoft Windows Search uses filters to extract the content of items for inclusion in a full-text index. You can extend Windows Search to index new or proprietary file types by writing filter handlers to extract the content, and property handlers to extract the properties of files. Filters are associated with file types, as denoted by file name extensions, MIME types or class identifiers (CLSIDs). While one filter can handle multiple file types, each type works with only one filter.
This topic contains the following sections:
Native Code
In Windows 7 and later, filters written in managed code are explicitly blocked. Filters MUST be written in native code due to potential CLR versioning issues with the process that multiple add-ins run in.
Secure Code Practices for Windows Search
The following are practices for writing secure applications for use with Windows Search.
For query applications:
- When writing search clients, you should choose the API that runs in a security context that allows the user the least privilege. For example, ASP pages can use the IXSSO query object, which runs as a user process.
For IFilters and Language Resources:
- If a new filter handler for a file type is being installed as a replacement for an existing filter registration, the installer should save the current registration and restore it if the new filter handler is uninstalled. There is no mechanism to chain filters. Hence, the new filter handler is responsible for replicating any necessary functionality of the old filter.
- IFilters, word breakers, and stemmers for Windows Search run in the Local Security context. They should be written to manage buffers and to stack correctly. All string copies must have explicit checks to guard against buffer overruns. You should always verify the allocated size of the buffer and test the size of the data against the size of the buffer. Buffer overruns are a common technique for exploiting code that does not enforce buffer size restrictions.
- IFilter, word breaker and stemmer components should never call the ExitProcess Function function or similar API that terminates a process and all its threads.
- Do not allocate or free resources in the DllMain entry point. This can lead to failures during low-resource stress tests.
- Code all objects to be thread-safe. Windows Search calls any one instance of a word breaker or stemmer in one thread at a time, but it may call multiple instances at the same time across multiple threads.
- Avoid creating temporary files or writing to the registry.
- If you use the Microsoft Visual C++ compiler, ensure that you compile your application using the /GS option. The /GS option is used to detect buffer overruns. The /GS option places security checks into the compiled code. For more information, see DllGetClassObject Function /GS (Buffer Security Check) in the Visual C++ Compiler Options section of the Platform SDK.
Additional Resources
- The IFilterSample sample demonstrates how to create an IFilter base class for implementing the IFilter interface.
- For an overview of the indexing process, see The Indexing Process.
- For an overview of file types, see File Types.
- To query file association attributes for a file type, see PerceivedTypes, SystemFileAssociations, and Application Registration.
Related topics