You can restrict the types of search filters that a given client might be allowed to use to prevent the use of potentially expensive filters, like range or substring searches.
You can use the allowed-filter-type property to provide a list of filter
types that can be included in the search requests from clients associated with the client
connection policy. This setting is only used if search is included in the set of allowed
operation types. This restriction only applies to searches with a scope other than
baseObject, such as searches with a scope of singleLevel,
wholeSubtree, or subordinateSubtree.
You can use the minimum-substring-length property to specify the minimum
number of non-wildcard characters in a substring filter. Any attempt to use a substring search
with an element containing fewer than this number of bytes is rejected. For example, you can
configure the server to reject filters like "(cn=a*)" and
"(cn=ab*)", but to allow "(cn=abcde*)". This property
setting is only used if search is included in the set of allowed operation types and at least
one of sub-initial, sub-any, or sub-final
is included in the set of allowed filter types.
There are two primary benefits to enforcing a minimum substring length:
- Allowing short substrings can require the server to perform more expensive processing. The search requires more server effort to assemble a candidate entry list for short substrings because the server has to examine more index keys.
- Allowing short substrings makes it easier for a client to put together a series of
requests to retrieve all the data from the server, a process known as "trawling". If a
malicious user wants to obtain all the data from the server, then it is easier to issue 26
requests like
"(cn=a*)","(cn=b*)","(cn=c*)", ...,"(cn=z*)"than if the user is required to do something like"(cn=aaaaa*)","(cn=aaaab*)","(cn=aaaac*)", ...,"(cn=zzzzz*)".