46 lines
1.2 KiB
Plaintext
46 lines
1.2 KiB
Plaintext
|
==== Validation
|
||
|
|
|
||
|
|
|
||
|
|
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 injections, the cleanest way to do so is to use parameterized queries
|
||
|
|
if it is available for your use case. An alternative is to
|
||
|
|
validate the input before using it in an LDAP query.
|
||
|
|
|
||
|
|
Input validation should be primordially done using native library sanitizers.
|
||
|
|
Alternatively, it can be implemented using an allow-list 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 validate on the server side. Not on
|
||
|
|
client-side front-ends.
|
||
|
|
|
||
|
|
As a last resort, 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`
|
||
|
|
|