как защититься от инъекций LDAP
Мы создаем приложение, которое использует LDAP через php и я. Задумался, есть ли что-нибудь, что вы можете сделать с инъекцией в LDAP, и еще лучше, как защитить себя от инъекций LDAP?
3 ответа
При создании фильтров LDAP вы должны убедиться, что значения фильтров обрабатываются в соответствии с RFC2254 :
Любые управляющие символы с ACII код <32, а также символы со специальным значением в фильтрах LDAP "*", "(", ")" и "\" (обратная косая черта) преобразуются в представление обратной косой черты, за которой следует два шестнадцатеричных символа цифры, представляющие шестнадцатеричный значение персонажа.
Zend_Ldap , например, использует следующую процедуру
//[...]
$val = str_replace(array('\\', '*', '(', ')'), array('\5c', '\2a', '\28', '\29'), $val);
for ($i = 0; $i<strlen($val); $i++) {
$char = substr($val, $i, 1);
if (ord($char)<32) {
$hex = dechex(ord($char));
if (strlen($hex) == 1) $hex = '0' . $hex;
$val = str_replace($char, '\\' . $hex, $val);
}
}
//[...]
Следует учесть, что привязка LDAP с именем пользователя (DN), но без пароля, считается анонимной привязкой. Поэтому, если вы проверяете, могут ли переданные учетные данные связываться через LDAP для проверки пользователя, если они передают пустой пароль, и вы передали его как есть, вы могли бы впустить кого-то неправильно.
В большинстве случаев используется учетная запись только для чтения для LDAP. Поскольку LDAP не справляется с записью, обновления происходят только в очень небольших разделах приложения, где можно использовать другую учетную запись.
Даже в этом случае язык запросов и язык обновления полностью разделены.
Чтобы защититься от отображения нежелательной информации, считайте весь пользовательский ввод испорченным и убедитесь, что испорченные данные никогда не используются, прежде чем они будут проанализированы, очищены и должным образом экранированы и скопированы в чистую переменную.
Точно так же вы можете подумать о том, чтобы выбрать только те данные, которые вы ожидаете от ответа, и вернуть их для отображения.