You'd have to be an idiot programmer to have a site succumb to this...
I'd have to say I disagree. I've been trying for a long time to convince many other coders I know to sanitize inputs. But the default way most coders seem prefer is concat'ing strings together to make their SQL statements. They don't want to use "bind" variables because it's too much work. I'm not saying it's not stupid, just that it's not uncommon.
Then there's the nature of this attack... Yes SQL injection has been around for a while, but in most SQL injection you either: 1) need to guess the name of a table and 2) needed to guess the name of one of the columns --BOTH of which take time to brute force, and only get you into One table on One site.
The reasons this exploit is so bad (and why it really is MS fault) is the nature of the attack. This (http://hackademix.net/2008/04/26/mass-attack-faq/) article shared by johnathan (44958) spells it right out:
1) "due to specific features of Microsoft databases, allowing the exploit code to be generic, rather than tailored for each single web site"
2) It makes use of the ability to assemble and "eval" SQL statements (and full stored procedures) on the fly from within a "SELECT" SQL statement! In the article it says this "powerful" DB technology is "a feature, not a bug". So don't expect for MS to release a patch that will plug this...
Usually SQL injection takes time to brute force, this attack is a 0-day single-shot that corrupts all text fields in all tables at once (it reads the SQL schema dictionary). And it doesn't matter which field it injects into. If you're not already sanitizing inputs, then it's actually likely that the first web hit you get from this bot will be the one that destroys.
This hack took down one of our sites 5 or 6 times in the last month. It's not our code. We inherited an IIS/VBScript/MSSQL nightmare and are busy rewriting the system from scratch in a LAMP stack. As it's not our code and we haven't gone through all of it, we just patch the holes as we find them. As the article says, the only way to protect against this is a complete code review (and in our case, rewrite) of every SQL query your app runs (1000+ of them). Oh, and don't miss one.
Moral of the story: don't assume that your code is SQL injection safe, or that your engineer isn't an "idiot", dump MSSQL asap, or find an option to turn off the "eval" function. If even one out of the thousand forms you have on your site has a single field that is not sanitized, this bot attack will crawl and find it.
Slashdot Mirror
You'd have to be an idiot programmer to have a site succumb to this...
I'd have to say I disagree. I've been trying for a long time to convince many other coders I know to sanitize inputs. But the default way most coders seem prefer is concat'ing strings together to make their SQL statements. They don't want to use "bind" variables because it's too much work. I'm not saying it's not stupid, just that it's not uncommon.
Then there's the nature of this attack... Yes SQL injection has been around for a while, but in most SQL injection you either: 1) need to guess the name of a table and 2) needed to guess the name of one of the columns --BOTH of which take time to brute force, and only get you into One table on One site.
The reasons this exploit is so bad (and why it really is MS fault) is the nature of the attack. This (http://hackademix.net/2008/04/26/mass-attack-faq/) article shared by johnathan (44958) spells it right out:
1) "due to specific features of Microsoft databases, allowing the exploit code to be generic, rather than tailored for each single web site"
2) It makes use of the ability to assemble and "eval" SQL statements (and full stored procedures) on the fly from within a "SELECT" SQL statement! In the article it says this "powerful" DB technology is "a feature, not a bug". So don't expect for MS to release a patch that will plug this...
Usually SQL injection takes time to brute force, this attack is a 0-day single-shot that corrupts all text fields in all tables at once (it reads the SQL schema dictionary). And it doesn't matter which field it injects into. If you're not already sanitizing inputs, then it's actually likely that the first web hit you get from this bot will be the one that destroys.
This hack took down one of our sites 5 or 6 times in the last month. It's not our code. We inherited an IIS/VBScript/MSSQL nightmare and are busy rewriting the system from scratch in a LAMP stack. As it's not our code and we haven't gone through all of it, we just patch the holes as we find them. As the article says, the only way to protect against this is a complete code review (and in our case, rewrite) of every SQL query your app runs (1000+ of them). Oh, and don't miss one.
Moral of the story: don't assume that your code is SQL injection safe, or that your engineer isn't an "idiot", dump MSSQL asap, or find an option to turn off the "eval" function. If even one out of the thousand forms you have on your site has a single field that is not sanitized, this bot attack will crawl and find it.
Hope this helps somebody... :)