LDAP-Suche nicht für bestimmte Zeichen auf einige Attribute

Question

Ich habe eine Abfrage, die etwa wie folgt aussieht:

(|(mail=andrew*)(cn=andrew*)(sn=andrew*)(telephoneNumber=andrew*)) 

also einen Suchbegriff aus einer UI nimmt und sucht nach einem Spiel gegen Begriff * über ein Bündel von Attribute.

Der Benutzer gibt in diesem Fall andrew und die App fügt den Platzhalter hinzu. Wenn der Benutzer andrew (rückwärtiges Häkchen) eingibt, sucht die App nach andrew *.

Ich habe festgestellt, dass, wenn Telefonnumber in den gesuchten Attributen enthalten ist, die Abfrage mit einer javax.naming.InvalidAttributeValueException fehlschlägt, wenn sie ausgeschlossen wird, funktioniert die Abfrage ohne Fehler.

Ich interessiere mich nicht besonders für das Backtick allein, aber da es kein besonderes Zeichen in LDAP-Suchen ist, frage ich mich, warum ich dieses Verhalten bekomme und ob andere Charaktere ähnliche Ergebnisse erzielen. Wird es etwas im Schema geben, das dies erklärt, wenn ich herausfinden kann, wie ich es abfragen soll, oder wird es etwas anderes sein?

Wenn es darauf ankommt, Zugriff über eine Spring-Bibliothek in einer Java-App.

Answer 1

Die Abfrage schlägt wahrscheinlich aufgrund von Attributwertbeschränkungen für das Attribut phoneNumber fehl. Die Syntax für die phoneNumber-Attribute ist in this RFC beschrieben. Back Tick scheint tatsächlich ein ungültiges Zeichen in den Telefonnummernwerten zu sein.

Nun könnte ich falsch liegen, aber beim Lesen Ihrer Frage scheint es, dass Sie versuchen, Filter mit String-Verkettung zu konstruieren. Bitte beachten Sie, dass Sie nie erstellen sollten Abfragen aller Art mit String-Verkettung, vor allem, wenn Teile der Abfragen von Benutzereingaben stammen. Ich bin mir sicher, dass Sie wissen, dass dies bei SQL-Abfragen der Fall ist, und dies gilt auch, wenn Sie LDAP verwenden.

Spring LDAP bietet zwei Möglichkeiten, LDAP-Abfragen zu erstellen. Der bevorzugte Ansatz ist die Verwendung der LDAP-Abfrage API dokumentiert here und (erweiterte Verwendung) here. Die alte veraltete - aber immer noch funktionierende - Art, dies zu tun, verwendet die Filterklassen, die in der alten Referenzdokumentation here dokumentiert sind.

Mit diesen Dienstprogrammen müssen Sie nicht verfolgen, welche Zeichen wann codiert werden müssen. Sie eliminieren außerdem jegliches Risiko für Anfrageninjektionsangriffe.