mysqli and PDO support multiple queries (the later having issue with multiple resultset, but can still execute em). As I've been shown earlier, only the basic mysql driver through mysql_query is lacking that support.
Also, a lot of PHP devs will also use Postgres, which do support it, and keep in mind that magic quotes only help with special characters based injection, which (while being the majority of them) isn't the only way to use sql injection attacks.
Actually, its not that tough in modern environments... Java,.NET, whatever, will have globalization enabled datetime objects, along with one or more parsing method, that most likely throw an exception if it cannot, and will return a datetime object otherwise...
So get the culture from the request, parse the date, if it throws an exception, return an error, otherwise pass the -datetime object- (not the string!) to the database API, and there really isn't anything that can happen. Even if an invalid date was to go through... its a datetime object (basically, a number of tick or something, depending on the environment), not a string or a vulnerable complex type, so not much to do.
Now if you were to try to validate the string yourself...good luck indeed.
In a good interview for a job thats beyond entry level, you don't ask silly questions. You start a discussion on the challenges and solutions involved in a given situation, and go from there.
Something like: "Have you ever had to work as a backend database developer?" "Yeah, I did in a 2 year contract at company XYZ" "Sweet, can you describe to me what you were doing?"::potential employe described it:: "Interesting. See, we're trying to do something similar here, but have stumbled on problem XYZ while trying to integrate some technology, we had performance issues in a query that did ABCD. What would you have done in that case?"
Of course, thats just an example, and a bad one, but I hope its enough to explain what I mean:)
I'm guessing your issues come from the way you work. If you do stored procedures the way I've done it everywhere I needed em (btw, I hate stored procedures, but not for any of the reasons you dislike them, so I'm not trying to defend a religious opinion!), you wouldn't have any issues.
Usually, you'll develop the SP in some kind of query builder tool. So you don't need to copy paste it anywhere, its already there. You just hit F5 (or whatever) to run it. It doesn't get much easier than that, all cute with syntax coloring, etc. The stored procedures are in text files on the disk, so you can grep them fine (and its easier too, since its not split by quotes and concat operators). For complex queries (several hundred lines), its also a boon, as doing that in the middle of PHP code would simply not be realistic, especially with the above mentionned quotes and +s and other irrelevent characters.
I guess you do save lines of code per queries...like... 2 (which aren't even visible if you use the appropriate methodologies).
And for your question about the magic quotes: its simple. The best way of doing things is by far and above (and not just for security reasons!) prepared statements. If you use preparated statements, all what things like magic quotes do is slow down your server. There's no reason to use it. The technical term for a feature that has -zero- use is "deprecated":)
Its simply redundant. (And again: preparated statements have many more advantages that magic quotes won't give you, such as performance, so you MUST use them, stored proc or not).
It isn't universal knowledge because its not taught in schools =P But considering how pervasive databases are in the industry, and that, after all, people go to school to (at least, quite often) become productive and get a job, it definately should be taught.
Its (for databases) on the same level as "Whats the difference between a WHILE and a FOR loop". Since the basics aren't taught, well...you have 500000 servers getting hacked (see article a couple notch down in today's list).
I'm sure there's a lot of things in embedded realtime systems that are required to know and aren't taught in school, too, but lets be honest... the DB Developer vs Embedded System Dev ratio is probably skewed toward the former, hehehe!
Oh, also to add to my reply: This was also limited to mysql_query (thus, mysql) when your original post stated "Database drivers", without refering to mysql specifically... Many other drivers are not as limited (so it was more of a mysql "feature" than PHP, and only of that PARTICULAR flavor, and only later in its PHP4 life). I'm sure mysql wasn't alone however, but it wasn't generalised.
Ok, it definately used to work (but it was pointless except for sql injection) so I'm guessing they removed it later in PHP4's life (it however is possible with mysqli extension)
It does work with PDO however, with the quirk that for mysql and sqlite (I think), you cannot move to the next rowset. That, I just tried.
No no no. This has a tons of potential holes, such as an encoding based attack in UTF16 or similar encoding. Use -prepared statements-.
Escaping/sanitizing is just one step up from validating. Let the -driver- do it for you, not the language or the framework. The database itself is the only one who truly knows how to handle itself, and drivers tap into that in prepared statements. -THAT- will protect you. Parameterized query APIs do -not- simply escape stuff in the back. Things are done at the level of the connection, chatting with the database API to create a cached/compiled version of the query, then plug in parameters -after- the query was parsed (so at that point its impossible to modify it).
That is -much- safer than just cleaning up a string (because it cannot abuse encoding/string related features), and has the extra advantage in many DBMS to also allow you to reuse query plan cache, thus improving performance and making it easier to benchmark and profile queries.
There are a lot of things about stored procedures, especially in large teams (like allowing a DBA to modify stored procedures without having to change the code written by other devs, and analysing their performance on a day by day scenario, sorting SPs in order of efficiency, getting SP reports, etc), and others involving auditing (in very large, critical scenarios, you'll have auditors that will look over your SPs with their related permissions to evaluated who can do what to your data, and thats simply not possible if your SQL is in your code). Debugging an SP using professional tools is also easier than debugging a mess of concatenated strings.
However, magic quotes being deprecated is probably for prepared statements (PDO). That has a lot of the advantages of SPs (not the ones I pointed above, but it protects against SQL Injection in the same way, and has the same performance benefits) without actually needing SPs. Escaping strings and whatsnot is simply not a good safety net. Thats why you have mysql_real_escape_string vs mysql_escape_string. And even that doesn't do it: there are attack vectors in certain situations involving encoding switching (it has been fixed, but it just shows what kind of issues can arise). There's also certain attack vectors that do not rely on special characters (such as a union attacks in a non-string query), though thats still hard.
Just used prepared statements, and you'll get the best of both worlds anyway. That said, saying that an SP increases code complexity implies that SQL is more complex than a typical programming language... which is really not the case. Its just that you're probably not as well trained in a set-based almost functional (not quite) programming paradigm as you are in "normal" programming. We all go through that =P
In this case, it doesn't even affect poorly written code: it affects some theoritical near-impossible scenario. I only skimmned the description, but as far as I can understand, you almost need a researcher to be able to write code that can be exploited... a normal (or bad) dev wouldn't be able to pull it off (neither would I, as far as I can tell!).
PHP does support multiple statements, and did all the way back in 2002 (probably before, but thats as far as my memory and references go). What it doesn't (and actually, thats limited to a few drivers such as MySQL and SQLite, even in the latest versions with PDO, as far as I can tell, though I do not use PHP anymore, so I'm going from a quick browse to know the current situation) support is multiple recordset.
So if you have multiple queries, it will execute them all. You just won't be able to move the cursor to the next result set. That was true of even mysql_query 6 years ago. It will work. (And even without them, you can just do a UNION to execute certain limited types of less destructive queries, though I feel you know that, since you specifically said multi-statements attack wouldn't work).
In any case: yes, multi statement attacks would work, but if you want to return data in an attack, you cannot do it in a second statement, you have to UNION it and hope the query is being returned in a grid-type fashion.
Windows ME was just Win98 with some more extensions to work better on a network, which was a minority at the time, especially since you COULD just use Win2k around the same time. So obviously, it was quite amazingly niche... (People who needed both the more advanced workgroup/domain fonctionalities, but still needed Win9x compatibility for games or whatsnot...not too many people!)
Exchange is one. Really, the "killer app" heavily varies from people to people. To some its the adobe suites (though available on non-Windows platform, doesn't have a perfect replacement in OSS, just like your Exchange example), to others its legit codecs for certain video types, for others its MS Office (again, before you point out OpenOffice... Exchange DOES have counterparts, just not acceptable ones for some people), for others its Visual Studio...
Your #2 really can be extended to douzans upon douzans of apps, and Exchange isn't even the biggest one (though it definately is among the biggests).
DB Programming (even the science part, such as the relational model) is virtually never taught in colleges. When it is, its as an elective class most of the time, even in the big name tear-through-your-wallet colleges.
Still cracks me up how in every interview I pass, I always get asked "Ok, so can you explain to me the difference between an inner and an outer join?" or "What is the main benefit of an index on a database table?". Shows the state of the workforce...
Nope, sorry:) One is caused by a noob using ASP/ASP.NET, the other is caused by a noob using PHP -or- someone who used mysql_escape_string instead of mysql_real_escape_string, which they were using because they learned PHP when prepared statements were not available or they didn't have access to PEAR before PDO came in or...
If the escape string methods (especially the "real" flavor) didn't exist, and prepared statements like in PDO had been built in (and not database specific) from the get go, you'd have a point.
MySQL 4 does have prepared statements (maybe you're thinking stored procedures?). The ODBC driver is a good point, but that becomes more of a configuration thing: if I use SQL Server through ODBC with multi statements at off, I'm not vulnerable either...in the same way as MySQL through native drivers will allow it. So its really not the platform. If you had a textbox where users can type a full sql query and executed it as is, you'd be vulnerable too (to variations of it anyway).
I guess a web based database development tool... But then, when you can execute ANYTHING and have admin priviledge on the database, you don't really need exploits:)
Yup. Basically, the only real way this could be exploited would be something like a stored procedure which takes one of the "vulnerable" types as parameters, exposed directly to the clients, and concatenate the types with little to no casting.
Something like (pseudocode, the following wouldn't even pass syntax check, obviously, but its stupid hard to find a working case)
DECLARE @blah SOMEVULNERABLETYPE
Exec "select * from stuff where stuff.Blah =" + @blah;
If @blah was a string, everyone would realise its vulnerable...but in this case, numbers, dates, etc, would be assumed safe (how do you put code in a number??), when it supposingly was discovered its not safe.
However, if you went through a database driver (not even an ORM!), and made a prepared statement, passed a Java (for example) variable as parameter to a query, well, no invalid input will be able to get through. If you add an ORM layer on top of that which does extra validation, then even if all of the types (both java and database) were vulnerable, it wouldn't go through either...
This is really more of a theoritical vulnerabilty than a real one... it can't realistically be exploited in the wild, and its hard to even -imagine- a scenario in a well coded app.
The "we trust our users" thing seriously drives me wacko... Statistically, most attacks (as in distinct attacks, not amount of systems affected) come from pissed off internal employes. While its not possible to protect against everyone (a bit tough to stop the lead DBA from running SQL against the database), at least doing the minimum...
I recently had to go to hell to get a vulnerability fixed in a software I was working on. The software had an expression evaluator that would read code from a user, compile it on the fly, and execute it, without validating it. I had to show my boss that I could wipe out everything the web server had write permission on (which was a lot, the app had to generate a lot of files) from the UI to have em beleive me (on a staging server, of course!).
Finally it got fixed, but originally the excuse was always "Well, our servers are not web facing, so who cares?!?!". But people don't seem to realise how quickly a computer-clueless user will learn basic programming if you fire them on a bad note...
PHP/MySQL get hit all the time. Multi-query works just fine. Its multiple resultset that has to be treated differently (and thats true for ASP.NET/MS SQL too).
They are being pretty dishonest, but not quite in the way one would think. The attack is targeted at ASP and ASPX pages, because they look -for the extension-. That is, if I have a web site that uses poorly written PHP with URL remapping to have my PHP scripts show up as ".aspx", I'll get attacked (and owned!) too. The SQL being injected is mostly SQL Server specific, but it doesn't attack a SQL Server -flaw-, it just uses Transact SQL syntax.
The actual flaw being exploited is SQL injection, which will be present in a LAMP too, if the code is written the same way (by using string concatenation from user inputs/cookies/query strings without validation/escaping/prepared statements). But in this particular case, the attack was targeting specifically ASP/ASP.NET pages (by looking at the extensions) with an SQL Server (or compatible) backend (by using Transact SQL).
So the "exploit" WOULD work on a LAMP, or on any other database driven web site that poorly written. But the attackers didn't -try-. Thats the only thing that makes it "Microsoft-only": the attackers didn't try to attack other platforms. The exploit however, is purely technology independant, and is pervasive on LAMP web sites too.
Whats sad however, is that I keep catching mainstream, "trusted" (I use the term loosely) sources for programing using string concatenation, be it in.NET, PHP, PERL, you name it. (Ruby and Java seems to be rarer, because of the prevalance of ORM, through things such as Hibernate and Rails, which, while available and extremely popular across the board, aren't as pervasive in the other ecosystems, mostly because of legacy mentalities).
Pick up a PHP or ASP.NET book at random at the library. One chance out of two that the first database tutorials use string concats like in your example. Look at random blogs from star developers from both the MS dev and OSS community. Again, v ery likely you'll find these same examples. Its really a sad sad world.
Well, web server updates wouldn't have helped much in this case. Patches don't help too much against SQL Injection, in the same way that no amount of patches will help you with buffer overflows or cross site scripting, if you don't check inputs and don't validate buffer sizes. This particular case may have been partly prevented because my understanding is that it partly used an actual server flaw, but if that many sites were SQL Injection vulnerable, nothing could have stopped an eventual exploit beyond simply coding the apps/web sites better.
Patches don't protect you against stupid programmers.
I understand where you're coming from, and you are right. My point was mostly that the article says "MS Web Servers hacked". When really its "bad web applications with SQL Server as the backend hacked", which is quite a far cry from what the article talk about. If the summary said "MS Databases hacked!", while it would still be totally stupid, it would already be a lil closer...
Slashdot Mirror
mysqli and PDO support multiple queries (the later having issue with multiple resultset, but can still execute em). As I've been shown earlier, only the basic mysql driver through mysql_query is lacking that support.
Also, a lot of PHP devs will also use Postgres, which do support it, and keep in mind that magic quotes only help with special characters based injection, which (while being the majority of them) isn't the only way to use sql injection attacks.
Actually, its not that tough in modern environments... Java, .NET, whatever, will have globalization enabled datetime objects, along with one or more parsing method, that most likely throw an exception if it cannot, and will return a datetime object otherwise...
So get the culture from the request, parse the date, if it throws an exception, return an error, otherwise pass the -datetime object- (not the string!) to the database API, and there really isn't anything that can happen. Even if an invalid date was to go through... its a datetime object (basically, a number of tick or something, depending on the environment), not a string or a vulnerable complex type, so not much to do.
Now if you were to try to validate the string yourself...good luck indeed.
In a good interview for a job thats beyond entry level, you don't ask silly questions. You start a discussion on the challenges and solutions involved in a given situation, and go from there.
::potential employe described it:: "Interesting. See, we're trying to do something similar here, but have stumbled on problem XYZ while trying to integrate some technology, we had performance issues in a query that did ABCD. What would you have done in that case?"
:)
Something like: "Have you ever had to work as a backend database developer?" "Yeah, I did in a 2 year contract at company XYZ" "Sweet, can you describe to me what you were doing?"
Of course, thats just an example, and a bad one, but I hope its enough to explain what I mean
I'm guessing your issues come from the way you work. If you do stored procedures the way I've done it everywhere I needed em (btw, I hate stored procedures, but not for any of the reasons you dislike them, so I'm not trying to defend a religious opinion!), you wouldn't have any issues.
:)
Usually, you'll develop the SP in some kind of query builder tool. So you don't need to copy paste it anywhere, its already there. You just hit F5 (or whatever) to run it. It doesn't get much easier than that, all cute with syntax coloring, etc. The stored procedures are in text files on the disk, so you can grep them fine (and its easier too, since its not split by quotes and concat operators). For complex queries (several hundred lines), its also a boon, as doing that in the middle of PHP code would simply not be realistic, especially with the above mentionned quotes and +s and other irrelevent characters.
I guess you do save lines of code per queries...like... 2 (which aren't even visible if you use the appropriate methodologies).
And for your question about the magic quotes: its simple. The best way of doing things is by far and above (and not just for security reasons!) prepared statements. If you use preparated statements, all what things like magic quotes do is slow down your server. There's no reason to use it. The technical term for a feature that has -zero- use is "deprecated"
Its simply redundant. (And again: preparated statements have many more advantages that magic quotes won't give you, such as performance, so you MUST use them, stored proc or not).
It isn't universal knowledge because its not taught in schools =P But considering how pervasive databases are in the industry, and that, after all, people go to school to (at least, quite often) become productive and get a job, it definately should be taught.
Its (for databases) on the same level as "Whats the difference between a WHILE and a FOR loop". Since the basics aren't taught, well...you have 500000 servers getting hacked (see article a couple notch down in today's list).
I'm sure there's a lot of things in embedded realtime systems that are required to know and aren't taught in school, too, but lets be honest... the DB Developer vs Embedded System Dev ratio is probably skewed toward the former, hehehe!
Oh, also to add to my reply: This was also limited to mysql_query (thus, mysql) when your original post stated "Database drivers", without refering to mysql specifically... Many other drivers are not as limited (so it was more of a mysql "feature" than PHP, and only of that PARTICULAR flavor, and only later in its PHP4 life). I'm sure mysql wasn't alone however, but it wasn't generalised.
Ok, it definately used to work (but it was pointless except for sql injection) so I'm guessing they removed it later in PHP4's life (it however is possible with mysqli extension)
It does work with PDO however, with the quirk that for mysql and sqlite (I think), you cannot move to the next rowset. That, I just tried.
What will break is your company's check book when the Oracle guys are done billing you for support :)
No no no. This has a tons of potential holes, such as an encoding based attack in UTF16 or similar encoding. Use -prepared statements-.
Escaping/sanitizing is just one step up from validating. Let the -driver- do it for you, not the language or the framework. The database itself is the only one who truly knows how to handle itself, and drivers tap into that in prepared statements. -THAT- will protect you. Parameterized query APIs do -not- simply escape stuff in the back. Things are done at the level of the connection, chatting with the database API to create a cached/compiled version of the query, then plug in parameters -after- the query was parsed (so at that point its impossible to modify it).
That is -much- safer than just cleaning up a string (because it cannot abuse encoding/string related features), and has the extra advantage in many DBMS to also allow you to reuse query plan cache, thus improving performance and making it easier to benchmark and profile queries.
There are a lot of things about stored procedures, especially in large teams (like allowing a DBA to modify stored procedures without having to change the code written by other devs, and analysing their performance on a day by day scenario, sorting SPs in order of efficiency, getting SP reports, etc), and others involving auditing (in very large, critical scenarios, you'll have auditors that will look over your SPs with their related permissions to evaluated who can do what to your data, and thats simply not possible if your SQL is in your code). Debugging an SP using professional tools is also easier than debugging a mess of concatenated strings.
However, magic quotes being deprecated is probably for prepared statements (PDO). That has a lot of the advantages of SPs (not the ones I pointed above, but it protects against SQL Injection in the same way, and has the same performance benefits) without actually needing SPs. Escaping strings and whatsnot is simply not a good safety net. Thats why you have mysql_real_escape_string vs mysql_escape_string. And even that doesn't do it: there are attack vectors in certain situations involving encoding switching (it has been fixed, but it just shows what kind of issues can arise). There's also certain attack vectors that do not rely on special characters (such as a union attacks in a non-string query), though thats still hard.
Just used prepared statements, and you'll get the best of both worlds anyway. That said, saying that an SP increases code complexity implies that SQL is more complex than a typical programming language... which is really not the case. Its just that you're probably not as well trained in a set-based almost functional (not quite) programming paradigm as you are in "normal" programming. We all go through that =P
In this case, it doesn't even affect poorly written code: it affects some theoritical near-impossible scenario. I only skimmned the description, but as far as I can understand, you almost need a researcher to be able to write code that can be exploited... a normal (or bad) dev wouldn't be able to pull it off (neither would I, as far as I can tell!).
I agree with the rest of your point, however.
PHP does support multiple statements, and did all the way back in 2002 (probably before, but thats as far as my memory and references go). What it doesn't (and actually, thats limited to a few drivers such as MySQL and SQLite, even in the latest versions with PDO, as far as I can tell, though I do not use PHP anymore, so I'm going from a quick browse to know the current situation) support is multiple recordset.
So if you have multiple queries, it will execute them all. You just won't be able to move the cursor to the next result set. That was true of even mysql_query 6 years ago. It will work. (And even without them, you can just do a UNION to execute certain limited types of less destructive queries, though I feel you know that, since you specifically said multi-statements attack wouldn't work).
In any case: yes, multi statement attacks would work, but if you want to return data in an attack, you cannot do it in a second statement, you have to UNION it and hope the query is being returned in a grid-type fashion.
Windows ME was just Win98 with some more extensions to work better on a network, which was a minority at the time, especially since you COULD just use Win2k around the same time. So obviously, it was quite amazingly niche... (People who needed both the more advanced workgroup/domain fonctionalities, but still needed Win9x compatibility for games or whatsnot...not too many people!)
Exchange is one. Really, the "killer app" heavily varies from people to people. To some its the adobe suites (though available on non-Windows platform, doesn't have a perfect replacement in OSS, just like your Exchange example), to others its legit codecs for certain video types, for others its MS Office (again, before you point out OpenOffice... Exchange DOES have counterparts, just not acceptable ones for some people), for others its Visual Studio...
Your #2 really can be extended to douzans upon douzans of apps, and Exchange isn't even the biggest one (though it definately is among the biggests).
DB Programming (even the science part, such as the relational model) is virtually never taught in colleges. When it is, its as an elective class most of the time, even in the big name tear-through-your-wallet colleges.
Still cracks me up how in every interview I pass, I always get asked "Ok, so can you explain to me the difference between an inner and an outer join?" or "What is the main benefit of an index on a database table?". Shows the state of the workforce...
Nope, sorry :) One is caused by a noob using ASP/ASP.NET, the other is caused by a noob using PHP -or- someone who used mysql_escape_string instead of mysql_real_escape_string, which they were using because they learned PHP when prepared statements were not available or they didn't have access to PEAR before PDO came in or...
If the escape string methods (especially the "real" flavor) didn't exist, and prepared statements like in PDO had been built in (and not database specific) from the get go, you'd have a point.
MySQL 4 does have prepared statements (maybe you're thinking stored procedures?). The ODBC driver is a good point, but that becomes more of a configuration thing: if I use SQL Server through ODBC with multi statements at off, I'm not vulnerable either...in the same way as MySQL through native drivers will allow it. So its really not the platform. If you had a textbox where users can type a full sql query and executed it as is, you'd be vulnerable too (to variations of it anyway).
I guess a web based database development tool... But then, when you can execute ANYTHING and have admin priviledge on the database, you don't really need exploits :)
Yup. Basically, the only real way this could be exploited would be something like a stored procedure which takes one of the "vulnerable" types as parameters, exposed directly to the clients, and concatenate the types with little to no casting.
Something like (pseudocode, the following wouldn't even pass syntax check, obviously, but its stupid hard to find a working case)
DECLARE @blah SOMEVULNERABLETYPE
Exec "select * from stuff where stuff.Blah =" + @blah;
If @blah was a string, everyone would realise its vulnerable...but in this case, numbers, dates, etc, would be assumed safe (how do you put code in a number??), when it supposingly was discovered its not safe.
However, if you went through a database driver (not even an ORM!), and made a prepared statement, passed a Java (for example) variable as parameter to a query, well, no invalid input will be able to get through. If you add an ORM layer on top of that which does extra validation, then even if all of the types (both java and database) were vulnerable, it wouldn't go through either...
This is really more of a theoritical vulnerabilty than a real one... it can't realistically be exploited in the wild, and its hard to even -imagine- a scenario in a well coded app.
The "we trust our users" thing seriously drives me wacko... Statistically, most attacks (as in distinct attacks, not amount of systems affected) come from pissed off internal employes. While its not possible to protect against everyone (a bit tough to stop the lead DBA from running SQL against the database), at least doing the minimum...
I recently had to go to hell to get a vulnerability fixed in a software I was working on. The software had an expression evaluator that would read code from a user, compile it on the fly, and execute it, without validating it. I had to show my boss that I could wipe out everything the web server had write permission on (which was a lot, the app had to generate a lot of files) from the UI to have em beleive me (on a staging server, of course!).
Finally it got fixed, but originally the excuse was always "Well, our servers are not web facing, so who cares?!?!". But people don't seem to realise how quickly a computer-clueless user will learn basic programming if you fire them on a bad note...
PHP/MySQL get hit all the time. Multi-query works just fine. Its multiple resultset that has to be treated differently (and thats true for ASP.NET/MS SQL too).
They are being pretty dishonest, but not quite in the way one would think. The attack is targeted at ASP and ASPX pages, because they look -for the extension-. That is, if I have a web site that uses poorly written PHP with URL remapping to have my PHP scripts show up as ".aspx", I'll get attacked (and owned!) too. The SQL being injected is mostly SQL Server specific, but it doesn't attack a SQL Server -flaw-, it just uses Transact SQL syntax.
The actual flaw being exploited is SQL injection, which will be present in a LAMP too, if the code is written the same way (by using string concatenation from user inputs/cookies/query strings without validation/escaping/prepared statements). But in this particular case, the attack was targeting specifically ASP/ASP.NET pages (by looking at the extensions) with an SQL Server (or compatible) backend (by using Transact SQL).
So the "exploit" WOULD work on a LAMP, or on any other database driven web site that poorly written. But the attackers didn't -try-. Thats the only thing that makes it "Microsoft-only": the attackers didn't try to attack other platforms. The exploit however, is purely technology independant, and is pervasive on LAMP web sites too.
+1 "Full of win" for you :)
.NET, PHP, PERL, you name it. (Ruby and Java seems to be rarer, because of the prevalance of ORM, through things such as Hibernate and Rails, which, while available and extremely popular across the board, aren't as pervasive in the other ecosystems, mostly because of legacy mentalities).
Whats sad however, is that I keep catching mainstream, "trusted" (I use the term loosely) sources for programing using string concatenation, be it in
Pick up a PHP or ASP.NET book at random at the library. One chance out of two that the first database tutorials use string concats like in your example. Look at random blogs from star developers from both the MS dev and OSS community. Again, v ery likely you'll find these same examples. Its really a sad sad world.
Well, web server updates wouldn't have helped much in this case. Patches don't help too much against SQL Injection, in the same way that no amount of patches will help you with buffer overflows or cross site scripting, if you don't check inputs and don't validate buffer sizes. This particular case may have been partly prevented because my understanding is that it partly used an actual server flaw, but if that many sites were SQL Injection vulnerable, nothing could have stopped an eventual exploit beyond simply coding the apps/web sites better.
Patches don't protect you against stupid programmers.
I understand where you're coming from, and you are right. My point was mostly that the article says "MS Web Servers hacked". When really its "bad web applications with SQL Server as the backend hacked", which is quite a far cry from what the article talk about. If the summary said "MS Databases hacked!", while it would still be totally stupid, it would already be a lil closer...