December 8, 2008 - 21:09 UTC - Tags: craftsman security testing escaping sql injection
Today was a disaster - I really messed it up.
After several rounds of interviews, I was lucky to get a job as mr. X apprentice. Mr. X was a notorious hacker for many years, but had now turned white hat and focused on improving security in the web application industry.
My first task at the new job, was to write an escaping routine to "get rid of all those nasty quotes and mitigate SQL-injection". I was excited and full of confidence. How hard could it possibly be?
Having already read through the first articles of Uncle Bob's excellent "The Craftsman"-series, I started out by writing unit tests and getting into TDD rythm.
But I also wanted to make sure my routine was as fast as possible. So by lunch I had three different versions ready - one using string replace, one using regular expressions and one using a stringbuffer.
After lunch Mr. X came down to check on my progress.
Mr. X: "Hey, how is it going?"
Me: "Well. I've written three different versions, and now I'm writing a small testscript to check which one is the fastest"
Mr. X sat down beside me, and glanced through my code, flipping back and forth from file to file.
Mr. X: "I see you are using TDD"
"Yes", I answered, trying not to sound too proud.
Mr. X still looking at the screen: "Well, it's too bad you forgot one test."
Blood rushed to my head, and my thoughts were racing through the tests. I had tests for small inputs, large inputs, several occurrences in a row... What did I forget?
Mr. X: "Instead of focusing on speed, you should have focused on writing good tests. It doesn't really help that it's blazing fast, if it's not doing the right thing."
Mr. X grabbed the keyboard, jotted down a new unit test, ran it and left. I sat there staring at red bar. His test read:
How could I have forgotten to escape the escape character? I had just learned a valuable lesson about escaping and premature optimizations...
Continue to part 2...
Comments closed for this post
After several rounds of interviews, I was lucky to get a job as mr. X apprentice. Mr. X was a notorious hacker for many years, but had now turned white hat and focused on improving security in the web application industry.
My first task at the new job, was to write an escaping routine to "get rid of all those nasty quotes and mitigate SQL-injection". I was excited and full of confidence. How hard could it possibly be?
Having already read through the first articles of Uncle Bob's excellent "The Craftsman"-series, I started out by writing unit tests and getting into TDD rythm.
But I also wanted to make sure my routine was as fast as possible. So by lunch I had three different versions ready - one using string replace, one using regular expressions and one using a stringbuffer.
After lunch Mr. X came down to check on my progress.
Mr. X: "Hey, how is it going?"
Me: "Well. I've written three different versions, and now I'm writing a small testscript to check which one is the fastest"
Mr. X sat down beside me, and glanced through my code, flipping back and forth from file to file.
Mr. X: "I see you are using TDD"
"Yes", I answered, trying not to sound too proud.
Mr. X still looking at the screen: "Well, it's too bad you forgot one test."
Blood rushed to my head, and my thoughts were racing through the tests. I had tests for small inputs, large inputs, several occurrences in a row... What did I forget?
Mr. X: "Instead of focusing on speed, you should have focused on writing good tests. It doesn't really help that it's blazing fast, if it's not doing the right thing."
Mr. X grabbed the keyboard, jotted down a new unit test, ran it and left. I sat there staring at red bar. His test read:
Assert.AreEqual(@"\\\'", EscapeSQLCharacters(@"\'"))How could I have forgotten to escape the escape character? I had just learned a valuable lesson about escaping and premature optimizations...
Continue to part 2...
About Erlend
Security guy with some thoughts on secure development.
Tag cloud
Categories
Blogroll
