January 3, 2009 - 11:39 UTC - Tags: craftsman security testing escaping sql injection input validation
The next morning I got my first go at a real system for a real customer. One of the company's clients had recently had a successful hacking attempt on one of their systems, and they wanted us to review and fix it.
Mr. X wanted me to spend the first hours of the day looking through the customer's code, see what functionality it was providing and how it stored its data. It was a java application for a webshop selling computer parts. It stored most of its data in a SQL database. However usernames and passwords were also stored in an LDAP directory.
After lunch, Mr. X came over to my office, and gave me some more information about the customer. Basically they had been lucky, and discovered the attack early.
"The attackers injected some test data while probing for SQL-injections. They were probably preparing to inject some malicious javascript or iframes", he told me.
"They did one mistake though. They injected the test data on one of the most popular products. So it didn't take long, before one of the webshop users reported the 'crappy description' and our customer took the site offline. We need to fix this as soon as we can, so they can get their site back online. They are loosing money by the hour. However we need to make sure we do the it the right way. So how do you suggest we do this?"
"Well...", I replied, "I guess we need to look at the input from the users. Probably we need to implement some input validation". I had been reading a lot about the recent SQL-injection attacks, and from what I had found in literature, lack of input validation seemed to be the root of the problem .
Mr. X: "All right. And how do you plan to implement it?"
Me: "Well...ehm...we need to check that order numbers and item numbers are valid"
Mr. X: "And how do you tend to do that?"
Me: "Ehm.... I guess we need to check that they don't contain characters that aren't numbers"
Mr. X: "Good. And what about things like addresses and names?"
"Well, we should ...", I said, but stopped halfway through the sentence. Numbers were easy, but an address could contain a lot of different characters. "...seeing how we are working on a SQL-injection problem, I guess we need to make sure the strings don't contain any characters that can cause SQL-injection".
"Go on", Mr. X said impatiently.
"So I guess we should make sure that single and double quotes are removed...", I replied.
"Do you think our CEO, Mr. O'Connor, would be happy with that solution?", mr. X said and grabbed his ringing cell phone.
Continue to part 3...
Go back to: Part 1
Comments closed for this post
Mr. X wanted me to spend the first hours of the day looking through the customer's code, see what functionality it was providing and how it stored its data. It was a java application for a webshop selling computer parts. It stored most of its data in a SQL database. However usernames and passwords were also stored in an LDAP directory.
After lunch, Mr. X came over to my office, and gave me some more information about the customer. Basically they had been lucky, and discovered the attack early.
"The attackers injected some test data while probing for SQL-injections. They were probably preparing to inject some malicious javascript or iframes", he told me.
"They did one mistake though. They injected the test data on one of the most popular products. So it didn't take long, before one of the webshop users reported the 'crappy description' and our customer took the site offline. We need to fix this as soon as we can, so they can get their site back online. They are loosing money by the hour. However we need to make sure we do the it the right way. So how do you suggest we do this?"
"Well...", I replied, "I guess we need to look at the input from the users. Probably we need to implement some input validation". I had been reading a lot about the recent SQL-injection attacks, and from what I had found in literature, lack of input validation seemed to be the root of the problem .
Mr. X: "All right. And how do you plan to implement it?"
Me: "Well...ehm...we need to check that order numbers and item numbers are valid"
Mr. X: "And how do you tend to do that?"
Me: "Ehm.... I guess we need to check that they don't contain characters that aren't numbers"
Mr. X: "Good. And what about things like addresses and names?"
"Well, we should ...", I said, but stopped halfway through the sentence. Numbers were easy, but an address could contain a lot of different characters. "...seeing how we are working on a SQL-injection problem, I guess we need to make sure the strings don't contain any characters that can cause SQL-injection".
"Go on", Mr. X said impatiently.
"So I guess we should make sure that single and double quotes are removed...", I replied.
"Do you think our CEO, Mr. O'Connor, would be happy with that solution?", mr. X said and grabbed his ringing cell phone.
Continue to part 3...
Go back to: Part 1
About Erlend
Security guy with some thoughts on secure development.
Tag cloud
Categories
Blogroll
