42 lines
1.1 KiB
Plaintext
42 lines
1.1 KiB
Plaintext
As a rule of thumb, the best approach to protect against injections is to
|
|
systematically ensure that untrusted data cannot break out of the initially intended logic.
|
|
|
|
For LDAP injection, the cleanest way to do so is to use parameterized queries
|
|
if it is available for your use case.
|
|
|
|
Another approach is to sanitize the input before using it in an LDAP query.
|
|
Input sanitization should be primarily done using native libraries.
|
|
|
|
Alternatively, validation can be implemented using an allowlist approach by
|
|
creating a list of authorized and secure strings you want the application to use in a
|
|
query. If a user input does not match an entry in this list, it should be rejected
|
|
because it is considered unsafe.
|
|
|
|
*Important note*: The application must sanitize and validate on the
|
|
server-side. Not on client-side front-ends.
|
|
|
|
The most fundamental security mechanism is the restriction of LDAP
|
|
metacharacters.
|
|
|
|
For **Distinguished Names** (DN), special characters that need to be escaped
|
|
include:
|
|
|
|
* `\`
|
|
* `#`
|
|
* `+`
|
|
* `<`
|
|
* `>`
|
|
* `,`
|
|
* `;`
|
|
* `"`
|
|
* `=`
|
|
|
|
For **Search Filters**, special characters that need to be escaped include:
|
|
|
|
* `*`
|
|
* `(`
|
|
* `)`
|
|
* `\`
|
|
* `null`
|
|
|