2

Will the C# DirectoryEntry class vulnerable to LDAP Injection from the parameters of it constructor?

For example:

DirectoryEntry de = new DirectoryEntry(path, username, txtPassword.Text, AuthenticationTypes.Secure);

DirectorySearcher search = new DirectorySearcher(de);
search.Filter = "(ACName=" + username + ")";
search.SearchScope = SearchScope.Subtree;
search.CacheResults = false;
...

I know that it is vulnerable to LDAP injection on the search.Filter, if the application accept user input without encoding / validation and set to search.Filter.

Will it cause any LDAP Injection vulnerability on the parameters of DirectoryEntry constructor like path, username, password if I did not validate / encode the user input and pass directly to the constructor?

Is there any others LDAP Injection point that I need to careful when I use user input?

Vilican
  • 2,703
  • 8
  • 21
  • 35
overshadow
  • 351
  • 3
  • 5
  • 17
  • 1
    The MOST important thing is to connect to the LDAP server with an account that has readonly access to the directory. – Ian Ringrose Oct 06 '15 at 11:02
  • What parameters are provided by the user and which are pulled from the application config? "path" isn't something normally provided by the end user. Also, what is the purpose of this function? If you're simply authenticating credentials I'd recommend using System.DirectoryServices.AccountManagement as noted here: http://stackoverflow.com/questions/290548/validate-a-username-and-password-against-active-directory – user2320464 Dec 05 '15 at 17:46

2 Answers2

0

Those values you supply to the constructor are used to pick the directory and authenticate. There are no performed queries, as far as I know, which renders the possibility of LDAP injection, impossible.

Yet, if you are paranoid as me, I would suggest performing the injection by hand on the queries (to know how it is done), and if you are successful, try to inject on the DirectoryEntry parameters.

Vilican
  • 2,703
  • 8
  • 21
  • 35
BrunoMCBraga
  • 466
  • 4
  • 12
0

Of course it is injectable, e.g. if you take part of the domain's DN from user input, they could obviously change the rest of the path and point at a different domain, or at a specific branch of the domain tree.

This would cause the consequent directory search to be based on whatever entry the maluser pointed you at, which could in turn cause different results based on your search. E.g. you might return and authorize the wrong user, because you expected to search within a different domain or OU.

AviD
  • 72,138
  • 22
  • 136
  • 218