On 11/9/03 12:13 pm, Ilya Martynov <[EMAIL PROTECTED]> wrote:
>>>>>> "CR" == Chris Ridd <[EMAIL PROTECTED]> writes:
>
>>> Is there built-in support in Net::LDAP for escaping parameters in
>>> search filters? Something like DBI's placeholders or at least a
>>> method/subroutine in public API which can escape strings for me.
>>>
>>> [..snip..]
>
> CR> I think the easiest solution is to just construct the filter object "by
> CR> hand".
>
> CR> filter => {
> CR> 'equalityMatch' => {
> CR> 'attributeDesc' => 'uid', 'assertionValue' => $user
> CR> }
> CR> },
>
> Thanks. I haven't seen it being documented in docs. Should it be
> updated? It would be nice if this or similar example were included
> too. Currently it just says that (perldoc Net::LDAP)
>
> filter => FILTER
> A filter that defines the conditions an entry in
> the directory must meet in order for it to be
> returned by the search. This may be a string or a
> Net::LDAP::Filter object. See Net::LDAP::Filter
> for a definition of the filter format.
It isn't documented. We can certainly update the docs...
> CR> To my mind this is more sensible than escaping the value into a string
> CR> representation, which then gets expanded out (and unescaped) into a HASH
> CR> ready for the encode!
>
> TMTOWTDI, using string representation certainly easier in many
> cases. Certainly adding a method/subroutine to do escaping in public
> API doesn't hurt especially as Net::LDAP already has code to do it.
Absolutely the string representation is easier, which is why there's a
string representation ;-)
It probably makes more sense to expose the escaping sub in Net::LDAP::Filter
than to document the structure of the Filter HASH. (Though we could point to
Convert::ASN1 for some indirect documentation of this. An example would
help.)
-----
=item escape ( ASSERTION )
Returns a copy of the ASSERTION string, suitably escaped for use in a filter
expression.
-----
It needs to say some more, but I can't think of some good words. It needs to
say that it shouldn't be used on expressions containing substring
assertions, but it should be used on each individual substring. i.e. if you
want "(cn=foo*)" then do "(cn=" . escape("foo") . "*)"
(Folks get confused with substring filters and think that the "wildcards" go
to the server.)
Any ideas?
> BTW I think clear documentation of how to properly construct search
> filters and/or do escaping is *very* important from security
> standpoint. Having done code review of code written by my co-workers
> I've noticed several LDAP injection vulnerabilities. Of course it is
> attributed to their ignorance. But I suspect partially it can be
> attributed to the fact docs does cover "the right way" to build search
> filters.
s/does/does not/ - I agree.
Cheers,
Chris
