January 4, 2009 - 10:17 UTC - Tags: craftsman security testing escaping sql injection input validation
After finishing the call, Mr. X came back into my office.
Mr. X: "So, did you find a solution for Mr. O'Connor?"
Me: "Well... I guess this is why you asked me to write that quote escaping routine earlier?"
Mr. X: "Now how to you plan to integrate this routine into the system?"
I thought about this for a while, and answered: "I guess, I'll add it here together with the other input validation routines. After all, this is where we are checking that the order numbers are actually numbers etc."
Mr. X looked at me for a while without saying anything. "Ok", I thought to myself, "obviously not the right choice".
Mr. X finally opened his mouth again: "So do you think that O'Connor is not a valid name?"
Me: "Ehm...Obviously not, but...ehm...."
Mr. X: "Then why do you think that escaping the quote in his name has anything to do with input validation?"
I just sat there silently for what seemed like an eternity.
"I thought", I stuttered, "that it would be good idea to keep the code related to input at the same place in the code base. That makes it easier to see where the security stuff is."
"Ok. Look over here", he replied and pointed at my screen. He flipped through a couple of files and brought up the code for registering a new user.
"Now, if the user fails to fill in some of the fields, data is returned to the user without being stored in the database. What do you think will happen to the name O'Connor?"
"It...will....probably...contain a slash?", I replied in a weak voice.
Mr. X: "And how do you suggest we avoid that?"
Me: "I....I guess we need to remove the slash... before we display it back to the user"
Mr. X: "And how do you plan to implement that?"
Me: "I guess I would first check if any of the fields are empty, and then escape the slashes if everything is ok."
Mr. X: "Let's back up a bit. Consider the registration of an order. To make sure an order is valid, you first need to check that the item number is numeric. Then you need to check that an item with that number actually exists in the database. Now you can store the order. So in many situations we touch the database before deciding whether or not to store input. The same might hold for say zip codes in this system."
I checked the code. And it did...
Me: "I see... So I guess we need to remove the slash just before we put the data back into the HTML of the registration form if something is wrong"
Mr. X: "But aren't you violating your own idea about having the "security stuff" as you put it, all in the same place?".
Me: "I guess...."
Continue to part 4...
Previous:
Go back to: Part 1, Part 2
Comments closed for this post
Mr. X: "So, did you find a solution for Mr. O'Connor?"
Me: "Well... I guess this is why you asked me to write that quote escaping routine earlier?"
Mr. X: "Now how to you plan to integrate this routine into the system?"
I thought about this for a while, and answered: "I guess, I'll add it here together with the other input validation routines. After all, this is where we are checking that the order numbers are actually numbers etc."
Mr. X looked at me for a while without saying anything. "Ok", I thought to myself, "obviously not the right choice".
Mr. X finally opened his mouth again: "So do you think that O'Connor is not a valid name?"
Me: "Ehm...Obviously not, but...ehm...."
Mr. X: "Then why do you think that escaping the quote in his name has anything to do with input validation?"
I just sat there silently for what seemed like an eternity.
"I thought", I stuttered, "that it would be good idea to keep the code related to input at the same place in the code base. That makes it easier to see where the security stuff is."
"Ok. Look over here", he replied and pointed at my screen. He flipped through a couple of files and brought up the code for registering a new user.
"Now, if the user fails to fill in some of the fields, data is returned to the user without being stored in the database. What do you think will happen to the name O'Connor?"
"It...will....probably...contain a slash?", I replied in a weak voice.
Mr. X: "And how do you suggest we avoid that?"
Me: "I....I guess we need to remove the slash... before we display it back to the user"
Mr. X: "And how do you plan to implement that?"
Me: "I guess I would first check if any of the fields are empty, and then escape the slashes if everything is ok."
Mr. X: "Let's back up a bit. Consider the registration of an order. To make sure an order is valid, you first need to check that the item number is numeric. Then you need to check that an item with that number actually exists in the database. Now you can store the order. So in many situations we touch the database before deciding whether or not to store input. The same might hold for say zip codes in this system."
I checked the code. And it did...
Me: "I see... So I guess we need to remove the slash just before we put the data back into the HTML of the registration form if something is wrong"
Mr. X: "But aren't you violating your own idea about having the "security stuff" as you put it, all in the same place?".
Me: "I guess...."
Continue to part 4...
Previous:
Go back to: Part 1, Part 2
About Erlend
Security guy with some thoughts on secure development.
Tag cloud
Categories
Blogroll
