January 4, 2009 - 14:17 UTC - Tags: craftsman security testing escaping sql injection input validation LDAP injection
"Now remember", Mr. X said, "that we are storing most of our user data in LDAP. But when we are storing orders, we store the name in our SQL database as a part of the shipping address. How do you suggest we handle LDAP injection with your approach?"
"LDAP...injection?", I stuttered.
"Yes", he replied. "LDAP also has a query language and injection attacks can occur here as well. But single and double quotes are not the dangerous meta characters for the version of LDAP used here".
"What's a....meta character?" I was embarrassed to ask, and my self-esteem was at an all time low.
"A meta character is a character that separates flow from control. So in a SQL statement the single or double quotes are what separates the actual query from the data in strings".
"I see", I replied almost unhearable.
"So for this version of LDAP, characters like "pipe" and "asterix" are meta characters. How do you suggest we handle them?"
"They are not used in names, so I guess we can remove them", I said.
"Yes, but let's focus on escaping for now. Where would you escape them?"
I looked back at the screen. If I escaped them where I escaped the SQL quotes, I would have string that was escaped for both LDAP and SQL. But it would also look wrong in each of the two systems as data stored in LDAP would have slashes in front of the quotes, and data stored in the SQL database would have the LDAP characters escaped. The data would be inconsistent.
"Well?", Mr. X said.
"I think I would escape the LDAP characters and remove the SQL escaping before sending it to the LDAP system"
"Ok, so you want to escape data for the subsystem you are talking to, just before sending the data to that system?"
"Yes", I replied without really thinking.
"Now, that doesn't sound so bad, does it? But why aren't you doing the same for SQL?"
I finally got his clues. Escaping data for a subsystem is not a part of input validation, because O'Connor is a valid name. Escaping data for a subsystem should be a part of code that communicates with the subsystem.
"I see", I said a bit more confident. "So we should escape data when we are sending it to a subsystem, because that's where we know what meta characters we have. And data may have meta characters even though the data is valid according to our input validation. So data can be valid, but still cause an injection attack?"
"Exactly", Mr. X said. Was that a smile? "Input validation is about making sure our data is valid according to the domain. Output escaping is about escaping data for a subsystem to make sure it doesn't cause harm".
Continue to part 5...
Previous:
Go back to: Part 1, Part 2, Part 3
Comments closed for this post
"LDAP...injection?", I stuttered.
"Yes", he replied. "LDAP also has a query language and injection attacks can occur here as well. But single and double quotes are not the dangerous meta characters for the version of LDAP used here".
"What's a....meta character?" I was embarrassed to ask, and my self-esteem was at an all time low.
"A meta character is a character that separates flow from control. So in a SQL statement the single or double quotes are what separates the actual query from the data in strings".
"I see", I replied almost unhearable.
"So for this version of LDAP, characters like "pipe" and "asterix" are meta characters. How do you suggest we handle them?"
"They are not used in names, so I guess we can remove them", I said.
"Yes, but let's focus on escaping for now. Where would you escape them?"
I looked back at the screen. If I escaped them where I escaped the SQL quotes, I would have string that was escaped for both LDAP and SQL. But it would also look wrong in each of the two systems as data stored in LDAP would have slashes in front of the quotes, and data stored in the SQL database would have the LDAP characters escaped. The data would be inconsistent.
"Well?", Mr. X said.
"I think I would escape the LDAP characters and remove the SQL escaping before sending it to the LDAP system"
"Ok, so you want to escape data for the subsystem you are talking to, just before sending the data to that system?"
"Yes", I replied without really thinking.
"Now, that doesn't sound so bad, does it? But why aren't you doing the same for SQL?"
I finally got his clues. Escaping data for a subsystem is not a part of input validation, because O'Connor is a valid name. Escaping data for a subsystem should be a part of code that communicates with the subsystem.
"I see", I said a bit more confident. "So we should escape data when we are sending it to a subsystem, because that's where we know what meta characters we have. And data may have meta characters even though the data is valid according to our input validation. So data can be valid, but still cause an injection attack?"
"Exactly", Mr. X said. Was that a smile? "Input validation is about making sure our data is valid according to the domain. Output escaping is about escaping data for a subsystem to make sure it doesn't cause harm".
Continue to part 5...
Previous:
Go back to: Part 1, Part 2, Part 3
About Erlend
Security guy with some thoughts on secure development.
Tag cloud
Categories
Blogroll
