SQL Injection [Pitch in!]

[Marc]

Some of our clients here at Vortech have been victims of SQL Injection. I would like to encourage our clients who have had this happen to them to post in here.

Some of our clients still have these issues, and because of the complexity of SQL Injection, and the uniqueness to each persons own database schema it would help if you shared your experience with our other members. Maybe everyone can work towards fixing these issues together.

Below are a few links to the latest SQL injection going around on the internet.

http://www.f-secure.com/weblog/archives/00001427.html

http://isc.sans.org/diary.html?storyid=4294

[cybergenius1]

Sounds like a good idea, how bout a forum just for topics like this? Like a security vulnerability discussion board.

[Brangwyn]

Whilst it sounds like a good idea to me, I'm not so sure having people post information that may aid in fixing but potentially also abusing vulnerabilities in a public forum isn't just asking for more trouble. Perhaps we could move the discussion to the customer only forum?

There really is a very simply solution to all SQL Injections, coders simply remember to sanitise all URL Input, most people tend to gloss over it becuase it takes more time and code, but you should always check your URL input's and make sure they're exactly what you expect them to be.

[levseltzer]

I have had a few of my clients suffer from SQL injections. The typical code was a page that was looking for an ID number. For example:
www.mypage.com/ProductDetail.asp?ID=3
In the page, I would have an SQL statement like this:
"Select * from Products where ID=" & request.querystring("ID")
The hacker would, however, replace the "3" with a complex SQL statement, and my select statement would actually process it!
See these articles for more information:
an article on wikipedia and an ASP solution at 4 Guys From Rolla

[Marc]

Originally Posted by levseltzer

I have had a few of my clients suffer from SQL injections. The typical code was a page that was looking for an ID number. For example:
www.mypage.com/ProductDetail.asp?ID=3
In the page, I would have an SQL statement like this:
"Select * from Products where ID=" & request.querystring("ID")
The hacker would, however, replace the "3" with a complex SQL statement, and my select statement would actually process it!
See these articles for more information:
an article on wikipedia and an ASP solution at 4 Guys From Rolla

Awesome post! I've read about this method, of would be hackers finding ID's to expolit.

[ixie02]

For php, the mysql_real_escape_string() function is helpful in sanitizing query strings.

[antic]

As a reseller, one of your "value adds" may be to provide such tips and code snippets, like a comprehensive SQL-sanitising function. Then clients can go to their devs and say, "hey are you following the guidelines laid down by my very switched-on hosting provider?"

It might be useful to start a thread which collects these snippets or tips, one per post. Then we can all dip into the same pool of wisdom.

The only real way of avoiding injection attacks is to avoid inline SQL altogether, and use stored procedures (commands & parameters) instead. Personally I often use "inline commands" which has the benefit of using parameters but is also easy to maintain when developing - coders often avoid stored procs while writing a new app as it's a pain to keep track of when requirements are changing a lot.

I was surprised a while ago that phpBB still uses inline SQL, so you're reliant on devs remembering to use mysql_real_escape_string() and such to sanitise the input.

Inline SQL is also much less efficient than using static SQL commands & parameters, as the SQL server can remember the optimisations for next time the same command is run.