January 5, 2009 - 22:15 UTC - Tags: craftsman security testing escaping sql injection input validation defense in depth
I thought about what Mr. X said for a while.
"But isn't output escaping enough to avoid SQL-injection?", I asked.
"Yes, you are correct. But remember, we don't only want to protect our app from SQL-injection. We want to protect our application from other attacks as well. And input validation will in many cases block attacks we didn't think of, because the attackers cannot get the malicious data into the system in the first place."
"But isn't this a kind of duplication? The DRY principle for clean code says we should say things in code only once"
"I agree that we should say things only once, but remember we are not doing the same thing. Input validation is about making sure the data is valid according to the domain. Output escaping is about making sure it doesn't harm our subsystems. So in stead of duplication, we use different security measures which sometimes mitigate the same problem in different ways."
"I see..."
"Another measure for limiting the effect of a SQL-injection would be to limit the rights of the user the application is using to access the database. By using different security measures that work in different ways, even though the attackers can get through one defense, they may not succeed in the attack. The principle of having several different security measures protecting the same asset in different ways, is often referred to as defense-in-depth"
What Mr.X said really made sense to me. But after all I had learned, I was becoming increasingly worried about my code.
"Well, after all you told me about white and black listing, I don't feel so confident about my SQL-escaping routine anymore. I mean I've added it in our customers code every place I found a SQL statement, and I think it's handling the quotes correctly. But..."
"A smart man once said: Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away. I have to admit I had a hidden agenda when I asked you to write that escaping routine..."
Continue to part 7...
Go back to: Part 1, Part 2, Part 3, Part 4, Part 5
Comments closed for this post
"But isn't output escaping enough to avoid SQL-injection?", I asked.
"Yes, you are correct. But remember, we don't only want to protect our app from SQL-injection. We want to protect our application from other attacks as well. And input validation will in many cases block attacks we didn't think of, because the attackers cannot get the malicious data into the system in the first place."
"But isn't this a kind of duplication? The DRY principle for clean code says we should say things in code only once"
"I agree that we should say things only once, but remember we are not doing the same thing. Input validation is about making sure the data is valid according to the domain. Output escaping is about making sure it doesn't harm our subsystems. So in stead of duplication, we use different security measures which sometimes mitigate the same problem in different ways."
"I see..."
"Another measure for limiting the effect of a SQL-injection would be to limit the rights of the user the application is using to access the database. By using different security measures that work in different ways, even though the attackers can get through one defense, they may not succeed in the attack. The principle of having several different security measures protecting the same asset in different ways, is often referred to as defense-in-depth"
What Mr.X said really made sense to me. But after all I had learned, I was becoming increasingly worried about my code.
"Well, after all you told me about white and black listing, I don't feel so confident about my SQL-escaping routine anymore. I mean I've added it in our customers code every place I found a SQL statement, and I think it's handling the quotes correctly. But..."
"A smart man once said: Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away. I have to admit I had a hidden agenda when I asked you to write that escaping routine..."
Continue to part 7...
Go back to: Part 1, Part 2, Part 3, Part 4, Part 5
About Erlend
Security guy with some thoughts on secure development.
Tag cloud
Categories
Blogroll
