2

I want to prevent SQL injection attacks. We have a form that asks for the user's AD username and password. Then our processing code looks something like this:

<cfldap name="ldap_result" action="query" server="999.999.999.999" 
attributes="userprincipalname,title,samaccountname,sn,name,mail,cn" 
filter="(&(objectclass=user)(sAMAccountName=#form.username#))"
start="dc=us,dc=company,dc=lan"
scope="subtree"
username="US\#form.username#" 
password="#form.password#">

I would never run a query with user input without cfqueryparam (to wrap the username and password inputs), but is something like that even available to cfldap? (We're on CF10 if that makes a difference.)

UPDATE:

To clarify, when I tried this, I got the following error:

Attribute validation error for tag CFLDAP.It does not allow the attribute(s) CFSQLTYPE,VALUE.

Nick Petrie
  • 5,364
  • 11
  • 41
  • 50
  • 1
    What happened when you tried it? My guess would be a compile error with words to the effect of using a queryparam tag outside a cfquery block. – Dan Bracuk Mar 23 '15 at 18:16
  • I get this: Attribute validation error for tag CFLDAP.It does not allow the attribute(s) CFSQLTYPE,VALUE. – Nick Petrie Mar 23 '15 at 18:47
  • Is the answer that it's not necessary since the form variables are being passed to a cf tag rather than directly into a SQL query? Can we rely on the tag doing the necessary escaping on the input when querying AD? – Nick Petrie Mar 23 '15 at 18:48
  • I second @DanBracuk's comment. Wouldn't it've been easy to simply *try this* rather than take the time to post a question on S/O, and ask other ppl to sink their time into it? – Adam Cameron Mar 23 '15 at 20:15
  • Sorry for the confusion, Adam. I did try it, and it failed. But, I didn't point that out in my original post. I'll make an update for future readers. – Nick Petrie Mar 29 '15 at 15:35

1 Answers1

5

No, you cannot use the cfqueryparam tag within your cfldap tag. The cfqueryparam is used specifically for SQL queries. You are thinking correctly though. NEVER TRUST USER INPUT

The cfldap tag does give you some protection in and of itself.

LDAP injection

ColdFusion uses the <cfldap> tag to communicate with LDAP servers. This tag has an ACTION attribute that dictates the query performed against the LDAP. The valid values for this attribute are: add, delete, query (default), modify, and modifyDN. All <cfldap> calls are turned into JNDI (Java Naming And Directory Interface) lookups. However, because <cfldap> wraps the calls, it will throw syntax errors if native JNDI code is passed to its attributes, making LDAP injection more difficult.

From page 14 of the ColdFusion 8 developer security guidelines which you should read if you have not done so already. It was written for ColdFusion 8 but much if not all of it is still relevant. There is an updated version of the document for ColdFusion 11 but it actually references the version 8 document as a reference as well.

I would suggest that you go with a whitelist approach here. Your active directory has specific requirements for the username and password fields; only lowercase and uppercase letters, numbers, etc. Create a regular expression that checks the user input for those valid characters only. If either field contains anything else then deny the submission and do not run the cfldap call.

Miguel-F
  • 13,450
  • 6
  • 38
  • 63
  • Thank you for that clarification. I was actually thinking I might go the route of a REReplace. It's a little bit of a pain as I don't make the rules on password requirements/restrictions so I'll need to track those rules down and rely on someone else to maintain them. But, it's better IMO than a free-for-all. – Nick Petrie Mar 23 '15 at 19:10
  • Agreed. There will be some maintenance with this approach (if/when the rules change) but definitely don't want to allow just anything. – Miguel-F Mar 23 '15 at 19:13
  • OWASP also provides for a reference implementation of encodeForLDAp(): https://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/reference/DefaultEncoder.html#encodeForLDAP(java.lang.String). If one is using untrusted values, one should also look to *actively* encode them correctly – Adam Cameron Mar 23 '15 at 20:18