Restricting the type of search filter used by clients
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
. This property setting is only used if search is included in the set of allowed operation types and at least one of ”(cn=ab*)“
, but to allow [.codeph]`”(cn=abcde*)"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*)"