Nous construisons une application qui utilise le LDAP via php et je dois penser, ce que vous pouvez faire tout ce que vous pouvez faire avec l'injection dans LDAP et mieux encore, comment se protège-t-on contre les injections du LDAP? p>
5 Réponses :
Dans la plupart des cas, il utilise un compte en lecture seule pour LDAP. Puisque LDAP est médiocre chez les écrivies, des mises à jour ne se produisent que dans de très petites sections de l'application dans laquelle un autre compte peut être utilisé. P>
Même alors la langue de requête et la langue de mise à jour sont complètement séparées. P>
Pour protéger contre l'affichage des informations non désirées Traitez toutes les entrées de l'utilisateur comme contaminées et assurez-vous que les données contaminées ne sont jamais utilisées avant d'être analysées, nettoyées et correctement échappées et copiées sur une variable propre. P>
De même, vous ne considérerez peut-être que la sélection des données que vous attendez de la réponse et de retourner cela à l'affichage. P>
"Pour protéger contre l'affichage des informations indésirables, traiter toute la saisie de l'utilisateur en tant que contaminée et que les données contaminées ne sont jamais utilisées avant d'être analysées, nettoyées et correctement échappées et copiées à une variable propre." Comment va-t-on faire cela est la question?
Un élément à considérer est qu'un LDAP se lier avec un nom d'utilisateur (DN) mais aucun mot de passe n'est considéré comme une liaison anonyme. Par conséquent, devriez-vous tester pour voir si les informations d'identification transmises peuvent être liées via LDAP pour valider l'utilisateur, s'ils passent un mot de passe vierge et que vous l'avez passé au fur et à mesure, vous pouvez laisser quelqu'un mal à malheur. p>
Merci, cela comprend et n'est pas vraiment une injection.
@Chris: convenu, pas vraiment une injection, mais dans le même espace de problème de base.
Après avoir lu cette réponse, j'ai immédiatement testé une application que nous avons en développement et ce problème particulier n'a pas été attrapé, merci!
Lors de la construction de filtres LDAP, vous devez vous assurer que les valeurs de filtrage sont gérées selon rfc2254 fort> :
n'importe quel personnages de contrôle avec une ACII code <32 aussi bien que les personnages avec une signification spéciale dans les filtres LDAP "*", "(", ")", et "\" (la barre oblique inverse) sont convertis en représentation d'une barre oblique inverse suivie de deux hex chiffres représentant l'hexadécimal valeur du caractère. p> blockQuote>
zend_ldap code> par exemple utilise la routine suivante p>
xxx pré> p>
Comment ferais-je assainir le mot de passe, car ces personnages spéciaux sont autorisés?
C'est exactement ce que le code ci-dessus fait ... Il transforme les caractères spéciaux et les codes. C'est comme des URL, imaginez si quelqu'un placez un paramètre et dans un paramètre, alors vous le convertissez. Juste parce que le mot de passe du navigateur / LDAP est intelligent et tente de corriger cette erreur pour vous, cela ne signifie pas qu'il est toujours correct d'envoyer des caractères spéciaux.
Essayé cette solution et cela ne fonctionne pas correctement. J'ai dû échanger des caractères hexagonaux avec: Array ("\ x5c", "\ x2a", "\ x28", "\ x29") pour le faire fonctionner.
@Kevinroth: Ce n'est pas vraiment possible. array ("\ x5c", "\ x2a", "\ x28", "\ x29") code> est en fait la même chose que le tableau
('\\', '",'" (',') ') code> tandis que RFC2254 nécessite que ces caractères soient remplacés par
' \ 5c ' code>,
' \ 2a ' code>,
' \ 28 ' code> et
' \ 29 ' code> littéralement.
J'entends ce que vous dites. Peut-être que ce que j'essaie d'accomplir est différent de l'OP. Après avoir effectué un LDAP_Search, je fais un LDAP_Bind pour l'authentification. Lorsque je remplace les caractères du mot de passe de l'utilisateur, la liaison retourne false. Je ne devrais peut-être pas remplacer les caractères du mot de passe en utilisant cette méthode? Comment puis-je protéger contre une injection dans le mot de passe? Merci!
@Kevinroth: Oui, vous ne devriez pas remplacer les caractères du mot de passe utilisé pour la liaison contre le LDAP. Cela s'échappe doit simplement se produire lorsque vous construisez des filtres LDAP pour avoir interrogé pour éviter les injections de LDAP (c'est l'équivalent LDAP d'une injection SQL).
function ldap_quote($str) { return str_replace( array( '\\', ' ', '*', '(', ')' ), array( '\\5c', '\\20', '\\2a', '\\28', '\\29' ), $str ); }
Bien que ce code puisse répondre à la question, fournissant un contexte supplémentaire concernant comment i> et / ou pourquoi i> il résout le problème améliorerait la valeur à long terme de la réponse.
dans PHP 5.6+ Vous devriez utiliser fonction LDAP_Escape Pour les valeurs de filtrage et les RDN. Tels que:
/** * Validate an attribute is an OID or a valid string attribute name. * * @param string * @return bool */ function isValidAttributeFormat($value) { $matchOid = '/^[0-9]+(\.[0-9]+?)*?$/'; $matchDescriptor = '/^\pL([\pL\pN-]+)?$/iu'; return preg_match($matchOid, $value) || preg_match($matchDescriptor, $value); } $attribute = 'sAMAccountName'; $value = 'foo'; if (!isValidAttributeFormat($attribute)) { throw new \InvalidArgumentException(sprintf('Invalid attribute name: %s', $attribute)); } $value = ldap_escape($value, null, LDAP_ESCAPE_FILTER); $filter = "($attribute=$value)";