Half a Million Microsoft-Powered Sites Hit With SQL Injection

Titus Germanicus writes to tell us that a recent attack has compromised somewhere in the neighborhood of 500,000 pages with a SQL injection attack. The vulnerability seems to be limited to Microsoft's IIS webserver and is easily defeated by the end user with Firefox and "NoScript." "The automated attack takes advantage to the fact that Microsoft's IIS servers allow generic commands that don't require specific table-level arguments. However, the vulnerability is the result of poor data handling by the sites' creators, rather than a specific Microsoft flaw. In other words, there's no patch that's going to fix the issue, the problem is with the developers who failed follow well-established security practices for handling database input. The attack itself injects some malicious JavaScript code into every text field in your database, the Javascript then loads an external script that can compromise a user's PC." Ignoring corporate spin-doctoring, there seems to be plenty of blame to go around.

Comments

Microsoft's Official View of the Situation

[eldavojohn]

Ignoring corporate spin-doctoring there seems to be plenty of blame to go around. Well, here's a quote directly from Bill Sisk of Microsoft (seems to be in line with this blogger):

Microsoft (NSDQ: MSFT) on Friday found itself trying to clarify that it has nothing to do with the poor coding practices that have enabled a massive SQL injection attack to affect Web sites using Microsoft IIS Web Server and Microsoft SQL Server. "The attacks are facilitated by SQL injection exploits and are not issues related to IIS 6.0, ASP, ASP.Net, or Microsoft SQL technologies," said Bill Sisk, a communications manager at Microsoft, in a blog post. "SQL injection attacks enable malicious users to execute commands in an application's database." Sisk said that to defend against SQL injection attacks, developers should follow secure coding practices. So if you want Microsoft's side of the story, they can't help it that people use bad coding practices.

As a coder, I don't agree with that. You make a tool/language/framework for developers, you better make it idiot proof. Example: C is far from idiot proof (seg fault!) but it's fast. Stupid fast. Unfortunately for C, there are more stupid coders out there like me than genuis coders out there like ... Donald Knuth. So you will see Java rise in popularity without ever being able to live up to speed of C.

Wow, for flaim retardant reasons, take the above paragraph as my meager opinion.

Re:Microsoft's Official View of the Situation

[duplicate-nickname]

So, I suppose all of the LAMP sites out there vulnerable to SQL injection are the fault of Microsoft too?

http://www.google.com/search?hl=en&q=site%3Asecurityfocus.com+php+sql+injection

Re:Microsoft's Official View of the Situation

[Anonymous Coward]

Flame retardant, eh?
Didn't think of Troll retardant, though!

LINUX GETS HAXXED DAILY BUT IT SUX AND THERE IS NOT 1/2 million Gnu/Linux servers out there because it sucks etc etc...

But really, though. Most smart databases should include some basic SQL injection protection. Its not like its a new concept. Using the same idea of C vs. Java, they should at least have easier to implement sql injection protection (input parsing) or limit the amount of commands coming in though the web app to minimize ammount of damage done.

Re:Microsoft's Official View of the Situation

[techno-vampire]

You make a tool/language/framework for developers, you better make it idiot proof

Why? It's not their responsibility to see to it that you can't write bad code for their program any more than it's the responsibility of car manufacturers to build cars that can't crash no matter how they're driven. There's only so much MSFT can do to protect lusers against their own stupidity, and if badly trained developers write vulnerable code, it's their own damned fault. I'm no Microsoft fanboi, but even I only bash them when they deserve it.

Re:Microsoft's Official View of the Situation

[0racle]

Do you post something similar when it's a PHP app on Apache being exploited with a SQL injection and the PHP authors say it's not their fault a whole bunch of their users are idiots?

Microsoft provides a platform, that platform has problems, but in this case the platform had nothing to do with what happened. This rests entirely on web developers who didn't bother to do things correctly.

Re:Microsoft's Official View of the Situation

[dedazo]

As a coder, I don't agree with that. You make a tool/language/framework for developers

So stock Java protects me from things like "SELECT * FROM users WHERE Name = 'eldavojohn'; DELETE FROM orders", correct?

Wait, it doesn't. Neither does PHP or Python or Perl.

So I guess you can spin it as this somehow being Microsoft's fault, and Slashdot can post it again (and maybe again tomorrow FTW), deliberately confusing pages vs sites and using titillating article titles and editorial bylines about how corporate spin is "bad".

That doesn't change the fact that this is an application vulnerability, much like the endless stream of exploits against applications like phpBB that run on Linux and Apache.

But hey, it's all in the name of freedom and increased ad revenue, right?

Re:Microsoft's Official View of the Situation

[Nefarious Wheel]

any more than it's the responsibility of car manufacturers to build cars that can't crash no matter how they're driven

Ref. "Unsafe at any speed" (R.Nader) and contrasting opinion "Safe at any speed" (L.Niven). The latter story was deliberate satire. Flying your car into a Roc can be inconvenient.

Re:Microsoft's Official View of the Situation

[Lobster Quadrille]

Actually, PHP's mysql engine won't run that query- you cannot execute more than one query in a single mysql_query() call.

There are plenty of ways around it, but your query will fail.

Re:Microsoft's Official View of the Situation

[Anonymous Coward]

So stock Java protects me from things like "SELECT * FROM users WHERE Name = 'eldavojohn'; DELETE FROM orders", correct?

Wait, it doesn't. Neither does PHP or Python or Perl.

Perl does.* PHP does.* I'd be extremely surprised if Python doesn't.* No idea about Java.

Maybe you should check your facts next time.

* Of course, it's not really meaningful to talk about a language protecting you from SQL injections; it's the database library that decides whether to send SQL to the database or not. I'm talking about the most popular libraries here (e.g. Perl's DBI).

Re:Microsoft's Official View of the Situation

[bit trollent]

C# allows for SQL parameters, which render sql injection all but impossible in most cases. It doesn't require that you use them, but makes them painfully easy to use.

By the way I have been forced to use a C# framework that was so jacked up that I ended up with no choice but to allow sql injection vulnerabilities. I got around this by making sure that every time I had to do that I would make sure that the input came from server side code which read an "int" and then converted it to a string to build the sql injection vulnerable command.

Par for the course, this framework was forced down my throat by someone with more seniority but far less common sense and skill.

Re:Microsoft's Official View of the Situation

[Sigma 7]

As a coder, I don't agree with that. You make a tool/language/framework for developers, you better make it idiot proof. Example: C is far from idiot proof (seg fault!) but it's fast. A seg fault is a form of idiot proofing - it prevents rogue C-style pointers from ruining the system. The absence of seg fault means your program is overwriting various locations in memory, which potentially causes the system to crash.

If you need access to locations of memory normally protected by a seg-fault, your operating system normally provides a means to do so.

Re:Microsoft's Official View of the Situation

[peragrin]

While I understand that why is it only MSFT IIS and MS SQL that's affected. If apache and MS SQL was being attacked and it has happened then i could fully understand it, but only MS IIS, MS SQL sites are affected. while the flaw may not be MSFT's sole fault how could 500,00 people setup a server wrong including the DHS? Maybe MSFT's history of poor coding and security practices lead to unsafe default options? security should always be over applied and then removed in layers.

Security like clothing works best in layers. You can always add a layer but you can only remove so many. prepare for an Arctic winter to start with, and you will have everything you need for the beach.

Re:Microsoft's Official View of the Situation

[MightyMartian]

No kidding. There are lots of things to blast Microsoft over, but to blast them over a common vulnerability that can be found on virtually every platform out there, and that has everything to do with crappy coding practices and a lack of understanding of why feeding HTML form input straight into a SQL query is so... fucking... bad...

I'd like to challenge the GP as to what particular set of tools alterations he would make to make injection attacks impossible.

Re:Microsoft's Official View of the Situation

[pembo13]

No, they are the fault of Linux obviously. Isn't that the normal assertion?

Re:Microsoft's Official View of the Situation

[Chokolad]

> * Of course, it's not really meaningful to talk about a language protecting you from SQL injections; it's the database library that decides whether to send SQL to the database or not. I'm talking about the most popular libraries here (e.g. Perl's DBI).

And this is differnt from Microsoft offerings how?

Re:Microsoft's Official View of the Situation

[dedazo]

you cannot execute more than one query in a single mysql_query() call

...is that an actual feature?

Seriously though, does it prevent you from running more than one *statement*, or a query *and* a DDL statement together? I guess that would be impressive.

I use mostly C# and MSSQL, and I routinely write stored procs that return multiple datasets, which wouldn't be a problem in this case, but would PHP prevent me from running an ad hoc statement that returns more than one resultset at a time? As far as I know I can do that with the SqlClient in .NET, but I graduated from the inline SQL happy club about a decade ago so I wouldn't really know.

Re:Microsoft's Official View of the Situation

[Anonymous Coward]

So if you want Microsoft's side of the story, they can't help it that people use bad coding practices.

As a coder, I don't agree with that. You make a tool/language/framework for developers, you better make it idiot proof. What are you, stupid? It is not Microsoft's, or anyone else's, fault that there are bad programmers in the world. It is not the fault of a language if someone using that language doesn't know what they are doing. People who describe themselves as "coders" might fall into the category of programmers who don't know what they're doing. I don't just write code, I design and develop applications. Much of what I do is research. I take it upon myself to learn about the security implications of what I'm doing and how to protect my applications. A SQL injection attack is just about the most widely-spread vulnerability online, and it's due in large part to a lot of the people like you see on any web development forum like the one attached to w3schools.com just copying and pasting PHP code around with no clue as to what anything does or why it does it.

There is absolutely no need or use in this world for an "idiot-proof" programming language. Programmers are expected to be people who are not idiots, at least when it comes to using computers (as opposed to dating). If you need an "idiot-proof" programming language in order to do decent work as a "coder", then save the rest of us programmers a future headache and find something else to do with your time.

Re:Microsoft's Official View of the Situation

[Dekortage]

Well, to quote from the Hackademix FAQ on this issue... "Crackers put together a clever SQL procedure capable of polluting any Microsoft SQL Server database in a generic way, with no need of knowing the specific table and fields layouts. There's no Microsoft-specific vulnerability involved: SQL injections can happpen (and do happen) on LAMP and other web application stacks as well. SQL injections, and therefore these infections, are caused by poor coding practices during web site development. Nonetheless, this mass automated epidemic is due to specific features of Microsoft databases, allowing the exploit code to be generic, rather than tailored for each single web site."

Re:Microsoft's Official View of the Situation

[mingot]

Holy shit, you mean if I use taint mode in perl this can't happen to me? Or mysql_real_escape_string in PHP? Just like if I used paramterized queries in C# I can also be similarly NOT fucked?

Re:Microsoft's Official View of the Situation

[Anonymous Coward]

You make a tool/language/framework for developers, you better make it idiot proof.

Hmm.. how about this instead:

If you are an idiot, then don't try to develop applications.

Really, if you are going to criticize the framework because of stupid developers, then you could probably lay blame with most frameworks out there.

Re:Microsoft's Official View of the Situation

[Sancho]

As others have posted, it's pretty easy to prevent multiple instruction SQL injection. That's a function of the database driver, which Microsoft controls.

It's much harder to prevent injection of additional parameters e.g. typing ' or '1'='1 into the text box--that's something that will be language and developer dependent. From my very brief scan of the details of this vulnerability, it looks like it would have been prevented if Microsoft had disallowed multiple statements in the driver.

This page supports my interpretation. I note, specifically:

Attackers carefully weighted the easiest spot, being a combination of

        * ASP classic, due to the poor coding standards among the average VBScripters who hardly known about prepared statements (even though they are supported)
        * ADO as the DB client layer, allowing stacked queries (multiple SQL statements together in a single string), which are not supported, for instance, by JDBC or by the mysql_query() PHP API
        * Microsoft SQL Server, because its Transact SQL supports a rich feature set including loops, metadata enumeration and Dynamic SQL (crucial for generalization), and because itâ(TM)s the most common ASP database back-end with such high-end features. Apparently, if stacked queries weren't allowed, this wouldn't nearly so easy to exploit.

Re:Microsoft's Official View of the Situation

[Anonymous Coward]

Since I have writen oh say 2000 web enabled forms in the last 10 years in ASP PHP ASP.Net JSP and ColdFusion I can simple say that yes you can SQL Inject all of them.

And yes C# has parameters but so does ASP if you use ADOVBS. There really is no excuse for not escaping inputs seriously form validation should always be done regardless. You might as well blame browser makers for allowing people to put semicolons into text boxes at all.

Re:Microsoft's Official View of the Situation

[Qzukk]

It\\'s broken, it\\\\\'s restrictive for normal users, and is a bad idea in the same way that forgiving developer for using bad html was, but it\'s there. never used it, but I know because of some bug that it was introducing in an unrelated application. Magic quotes is the absolute coolest thing since sliced arrays, or my name isn\\'t Jeffery O\\\\\\\\\\\\\\\\'Donnel!

Re:Microsoft's Official View of the Situation

[Cal Paterson]

Ref. "National Highway Traffic Safety Administration".

I'm aware this is pretty tangential, but I found it interesting that the Corvair was eventually rated to be a pretty reasonable car by the government body that Nader's book created.

Re:Microsoft's Official View of the Situation

[dedazo]

it looks like it would have been prevented if Microsoft had disallowed multiple statements in the driver.

So what you are saying is that (and quoting the article you reference) Microsoft is at fault for providing these "high end features"? Even considering that it's not necessary to write sloppy VBScript code, and that it's ridiculously easy to use ADO to put together parameterized database commands, regardless of how many resultsets they are supposed to return?

And that the lack of that feature is actually an advantage for platforms like PHP and Perl? I'm curious, is the lack of that feature the reason for the multiple and well-documented injection attacks against LAMP applications? Or is it something else?

You will forgive me here if I imagine for a second what the general sentiment would be if the PHP MySQL driver actually provided this useful time- and bandwidth-saving feature while ADO/ADO.NET didn't. You would be telling me that it's the developers' fault, since all they need to do is write half-decent code that uses simple and well-documented features in the DB framework that prevent exposure to injection attacks. The PHP folks would not to blame, and in fact it would be so cool of them to out-innovate Microsoft.

Re:Microsoft's Official View of the Situation

[Architect_sasyr]

Security, Usability, (Lack of) Cost. Pick Two.

I'm sure if Microsoft didn't have those features in their databases someone would complain about it pretty severely.

Also, why do we never see Oracle vulnerabilities making the front pages? During my pen-tests I am more likely to come across Oracle servers than SQL Sewer...

Re:Microsoft's Official View of the Situation

[cheater512]

The thing is that only Microsoft servers are affected by this type of automated attack.

Its a Microsoft flaw in my book.

Re:Microsoft's Official View of the Situation

[mithras invictus]

If PHP had a framework where any moron could click through a few wizards and come out with something resembling a product (program/website/whatever) and call himself a programmer while those "applications" communicate with sophisticated (and usually half-documented) mechanisms you bet i would blame them for being part of the problem. Microsoft has given the IT industry an alarming number of so called "programmers" that are actually nothing more than end users of their technology platforms.

Re:Microsoft's Official View of the Situation

[Sancho]

So what you are saying is that (and quoting the article you reference) Microsoft is at fault for providing these "high end features"? No, that's not what I said. I said that Microsoft could have prevented it, not that they were at fault. There's a world of difference.

And that the lack of that feature is actually an advantage for platforms like PHP and Perl? I think that the protection against multiple statements in the MySQL driver for PHP and Perl is an advantage, yes. Much in the same way that I would consider default-bounds checking in a language an advantage. It'd be even better if you could explicitly turn the feature off in order to use "unsafe" statements. The C API to MySQL allows this--I'm not sure if the PHP version does, because frankly, I've never encountered a situation where I needed this behavior.

I'm curious, is the lack of that feature the reason for the multiple and well-documented injection attacks against LAMP applications? Or is it something else? Are you being sarcastic, or am I inferring incorrectly? Damned lack of inflection in plain text....

Disallowing multiple statements does not prevent SQL injection. It prevents injecting new statements. It's still quite possible to inject unintended content into the query.

Morevover, I understand that the multiple statement protection is relatively new, so who knows if it would have had a large impact on the number of injection vulnerabilities in applications built on LAMP.

You will forgive me here if I imagine for a second what the general sentiment would be if the PHP MySQL driver actually provided this useful time- and bandwidth-saving feature while ADO/ADO.NET didn't. Well, I think that the bandwidth and time savings are going to be fairly minimal. I'd like to think that I'd feel the same way if this situation were reversed.

And like I said from the beginning of this post, I'm not laying blame solely on Microsoft. Quite obviously, the developers are at least 50% culpable. But the truth is, I don't understand the usefulness of this feature, and it has shown to allow for a great deal of harm. There's something to be said for anticipating security problems with features before you add them (take, for example, register_globals in PHP--a useful feature to the lazy programmer, but the bane of security analysts. I'd much rather that feature have never seen the light of day.)

Ultimately, I'm no fan of PHP for the same reason. It's a poorly designed language that lets the developer shoot himself in the foot far too easily. It's also easy to use, so it's attracted a large number of non-programmers. The combination of the two means that there are huge numbers of flaws in PHP applications. If PHP were more strict, these flaws wouldn't exist. I've probably even got a PHP rant or two hanging around on Slashdot....

Re:Microsoft's Official View of the Situation

[Anonymous Coward]

Hehehe, dude,
Any RDBMS like ORACLE or MS SQL has reach set of permissions you can set on table. I've rarely seen developers actually care about those and their code would execute even read-only query under account with full permissions. If evil Mr DBA does not straighten them up they tend to remain ignorant. Even then usually nobody gets fired :-(

Re:Microsoft's Official View of the Situation

[Nefarious Wheel]

Yes -- in particular I thought the later cars were a good design, and still do. They moved from swing axles to half shafts and that cured their handling woes. Nice little turbocharged mid-engine flat six, could have been a Porsche competitor if GM had just stuck to their guns and took credit for the improvement in quality instead of pretending it never happened. I guess that would have given credit to some outside person, though -- nobody outside the corporation can ever be "right". ./offtopic

Re:Microsoft's Official View of the Situation

[mrbluze]

As others have posted, it's pretty easy to prevent multiple instruction SQL injection. That's a function of the database driver, which Microsoft controls.

Actually, if we could wipe SQL off the face of the earth then we wouldn't have SQL injection attacks. I mean, for a person to be able to escape the bounds of a variable by simple insertion of code into a text field is pretty outrageous, really.

Whoever is walking around saying that they have a good product which requires programmers to use or even have to create(!) special functions to filter every bit of input to prevent injection attacks, is lying out of their posterior. It's not a good product.

Prepared statements are a good thing. The real fix, though, is to prevent the usage of SQL for database modification, but force this activity to occur through the usual data handling methods for their programming language. Eg: if you are inserting a string into your database, then you should need to pass a string as a variable to a function, and not be allowed put it in raw into an SQL query.

I thought after so many compromises, so many reports and such an obviously open problem, there would no-longer be this issue. IMHO the fear of offending lazy or sloppy programmers is not an excuse to fix fundamental security problems in a language.

Re:Microsoft's Official View of the Situation

[dedazo]

This is not rocket science here. The 100% certified, no-assembly-required, Makes Baby Jesus Happy (TM) solution to this "problem" is to use your database's built-in programmability feature (better known as stored procedures) every single time you need to pull data push data from your database. No exceptions. And that's it. Stop using lame inline SQL.

I hear even MySQL supports stored procedures now, so I don't see what the problem is, other than millions of lines of sloppy existing code that won't die. But the "fix" has always been there.

Re:Microsoft's Official View of the Situation

[PIBM]

posterior. It's not a good product.

Prepared statements are a good thing. The real fix, though, is to prevent the usage of SQL for database modification, but force this activity to occur through the usual data handling methods for their programming language. Eg: if you are inserting a string into your database, then you should need to pass a string as a variable to a function, and not be allowed put it in raw into an SQL query.

Hehum. Your proposal would do nothing to fix the problem. You are still able to send a string which contain quotes (yes, quotes are characters and parts of a string!) so it's still possible to exploit.

Re:Microsoft's Official View of the Situation

[Jeff Molby]

So what you are saying is that (and quoting the article you reference) Microsoft is at fault for providing these "high end features"?

Like most MS security holes, the problem isn't that features are available, it's that they're turned on by default.

Re:Microsoft's Official View of the Situation

[mrbluze]

Your proposal would do nothing to fix the problem. You are still able to send a string which contain quotes (yes, quotes are characters and parts of a string!) so it's still possible to exploit. If you are sending your variable to a function then it's the function's responsibility to escape quotes and do all the garbage collection. That's the point. Bye bye SQL.

Re:Microsoft's Official View of the Situation

[Anonymous Coward]

There is nothing at all in the exploit that couldn't be duplicated on other platforms in just as much of a 'generic' way using cursors and querying the information_schema or data dictionary for the right fields to change. This is PURELY the result of lousy web development.

Re:Microsoft's Official View of the Situation

[SCHecklerX]

One reason I use Embedded Perl and never bothered with learning PHP. It actually requires effort to not at least escape untrusted input.

Re:Microsoft's Official View of the Situation

[I'm Don Giovanni]

So the proper thing to do is to cut features, even if they have no inherent flaw, for fear that they might be exploited due to sloppy coding by others? That mindset has always bugged me. Seems backwards.

Re:Microsoft's Official View of the Situation

[Gracenotes]

fyi: Java won't protect you when submitting a generic java.sql.Statement, but will for a properly used java.sql.PreparedStatement (which extends Statement). Escapes strings and all automatically.

Re:Microsoft's Official View of the Situation

[gadzook33]

Thank you. I love when I have to read through comments to get a concise explanation of the problem.

Re:Microsoft's Official View of the Situation

[Anonymous Coward]

I agree. Bad programmers should be able to crash the kernel by corrupting its internal structures. The very notion that some would restrict execution to specific blocks of memory... just plain stupid. Just let them overwrite what ever memory they want and execute it. Let them burn for their stupidity.

Rock'n'roll dude!

Re:Microsoft's Official View of the Situation

[metallic]

That's because they were using something called SQL injection to execute arbitrary code in the database. The reason this only effects Microsoft platforms is because they code they were injecting is quite specific to MS SQL Server.

And this isn't a server configuration problem. This is shoddy coding on the part of the programmers that created the websites that got hacked. The same thing could happen to something running PostgreSQL + PHP + Apache.

Re:Microsoft's Official View of the Situation

[Allador]

That is incorrect.

Only Microsoft servers are affected by this specific attack.

Nearly every language and/or platform in existence right now is capable of being hit by this type of automated attack.

Nearly every mainstream DB server allows things like INFORMATION_SCHEMA or similar metadata to be accessed in this way to generically hit all tables in a db/schema.

Every single web-based language that I've ever seen is quite capable (trivial even) to create sql-injection vulnerable pages.

Re:Microsoft's Official View of the Situation

[Allador]

why is it only MSFT IIS and MS SQL that's affected Because the code they used is based on the MS-SQL particular dialect, with some MS-SQL specific conventions.

The malware authors could have trivially used INFORMATION_SCHEMA views rather than sysobjects, and this would have been a generic attack that would have worked against most mainstream db servers.

while the flaw may not be MSFT's sole fault how could 500,00 people setup a server wrong including the DHS? This has nothing, zero, to do with server setup or configuration. This is purely and soley, only has to do with web app developers allowing uncleansed commands to be sent from a web-browser to the underlying db server.

Again, the ONLY reason this only works on MS-SQL is because the malware authors made a choice to write the attack in non-portable syntax. They could have done so, but they chose not to.

Re:Microsoft's Official View of the Situation

[Allador]

You keep saying 'multiple statement protection' as if allowing multiple statements in a batch is a bad thing that should be prevented by any sane person.

Allowing multiple statements (and multiple active result sets) is a commonly used feature for many legitimate purposes. It's not something bad to be blocked. Nearly every major db platform provides this.

Some of the language-specific adapters to said sql servers never got around to implementing this feature, but its not blocked because its a security risk.

Saying so is roughly equivalent to saying governments should enact 'metal protection' and outlaw all forms of metal, just because its possible to use metal to make a knife and hurt people.

Re:Microsoft's Official View of the Situation

[Allador]

There are other simpler solutions that arent so painful or intrusive.

The easiest is just to use prepared/parameterized queries.

I think many of us have gone through the 'everything should be stored procedures' phase, but that really only works for a niche (albeit a large one) of app development.

Re:Microsoft's Official View of the Situation

[ianare]

mysql_query() sends an unique query (multiple queries are not supported) A query being any command, anything after the ';' is not executed.

Re:Microsoft's Official View of the Situation

[ianare]

And that the lack of that feature is actually an advantage for platforms like PHP and Perl? Yes. The proper way of running a large number of prepared statements is by using stored procedures.

Re:Microsoft's Official View of the Situation

[mrterrysilver]

i can not believe the unbelievable biased title for this story. this has nothing to do with microsoft flaws and everything to do with bad developers yet somehow the title implies that a microsoft flaw caused 500,000 compromised servers... wtf?

this can happen on any type of system it really has nothing to do with microsoft. can't you find something real to complain about?

i know the slashdot community is anti-microsoft but writing and publishing incorrect and extremely negatively biased stories like this make me want to get my tech news elsewhere. bad form slashdot

Re:Microsoft's Official View of the Situation

[TheThiefMaster]

A seg fault can happen if you try to read/write to a memory address which refers to some unmapped virtual memory, as well as it being a memory page that you don't have read/write permissions for.

In the former case there is quite literally no memory at that location to write to.

Re:Microsoft's Official View of the Situation

[Guignol]

No
It could just be disabled by default as it is most likely not what most calls intend to use
And of course have an option, or a separate call to allow it as such

Re:Microsoft's Official View of the Situation

[jotok]

Nah. Any language is supposed to let you do EXACTLY what you want to do. It's just that people don't know how exact they have to be, or don't care. All of the mistakes in this case are the fault of the people who coded the ASP script running on the server, or who managed the server permissions.

Re:Microsoft's Official View of the Situation

[TheRaven64]

Nearly every mainstream DB server allows things like INFORMATION_SCHEMA or similar metadata to be accessed in this way to generically hit all tables in a db/schema. Isn't this kind of metatable the kind of thing that should not be accessible by the db user running the web app, just by the DBA user? It seems like poor privilege separation if every user can access it. I don't know if other databases make the same choice, but if they do then I would say that they are equally wrong, rather than making Microsoft's implementation valid.

Re:Microsoft's Official View of the Situation

[zLaSh]

An idiot proof language/compiler/framework is not the solution. Its of course cheaper for employers to have programmers, with little or not training, that can get pseudo-random sentences from the documentation and with a little percentaje of luck get to something that works. But, as someone who likes computers and cares about technology advancement, this is not the right way. If I buy the lastest PC, It will annoy me that I can only run a notepad, because it runs in a VM, inside a VM, inside a VM, and only because lack of education of the programmers, and excess of greed on employers.

Re:Microsoft's Official View of the Situation

[jotok]

SQL injection is not a "Microsoft vulnerability." You find the same issues with Oracle, MySQL, postgresql, etc., they are simply executed differently.

Re:Microsoft's Official View of the Situation

[ta bu shi da yu]

Someone mod the parent up please.

Re:Microsoft's Official View of the Situation

[jotok]

First off, why would you expect DHS to be secure? They get low scores on cybersecurity along with the rest of the government. Also, I know for experience what a soup sandwich their C4 systems are.

Second, imagine for a second how many websites are out there that present content using ASP and a SQL backend. Understand that the vast majority of their designers took the time to set permissions correctly and sanitize inputs, like good developers. That 500,000 of them failed to do so does not make it Microsoft's problem.

Re:Microsoft's Official View of the Situation

[jotok]

What if I submit several statements as a string and the "command" is to concatenate and run them? I understand PHP won't do it (unless you fail to validate the input) but what about the server itself?

Re:Microsoft's Official View of the Situation

[plague3106]

Um, the only way to fix this would be to disallow any ad hoc queries and force use of stored procedure calls. I don't think that would fly to well, as pretty much every platform (including LAMP) includes ways to send arbitrary text to any sql server.

Oh, and what the hell does C have to do with anything? Any language can be vunerable to sql injection attacks.

Re:Microsoft's Official View of the Situation

[nametaken]

It's good that you posted this. I was wondering how a SQL Injection attack could POSSIBLY be Microsoft or .Net related, unless there was some flaw in parameterized inserts in SQLClient, or some such.

Further, I don't know how this could be at all scriptable only for MS based sites. AFAIK, compounding statements by exploiting ad-hoc queries and lack of string cleaning is an issue that could pertain to any framework and DB vendor?

Does anyone know how this could be vendor specific??

Re:Microsoft's Official View of the Situation

[nametaken]

Precisely. An idiot-proof framework is a useless framework.

If you're writing ad-hoc queries without special character checking, how can MS possibly save you from yourself? By removing the ability to perform queries without parameterization and by putting their own string-cleaning right in the sqlclient? Imagine how pissed the masses would be if they did that without a way around it.

It's a shame that I see this all the time. I frequently notice it when I use a special character in a form and get a stacktrace indicating a failed (and unhandled) insert/update... but I can't even begin to justify blaming Microsoft for that.

I hate to sound abusive about this, as I'd only consider myself a mediocre programmer to begin with, but this looks like it rests solely on the programmer who writes shit code.

Re:Microsoft's Official View of the Situation

[nametaken]

That would be intentionally retarding the capabilities of the framework to protect us from ourselves, and we'd be pissed about it.

It would be like saying they should disallow file system access via System.IO because someone could exploit bad code to write to the server's filesystem.

Re:Microsoft's Official View of the Situation

[Sancho]

There should certainly be a way to perform multiple statements in a single call, but it should not be the default. Just like we disallow kernel calls unless you do it in a special way because they are dangerous.

Unfortunately, it seems like the majority of Slashdotters can't seem to think beyond the printed words on the screen. It makes me sad--there was a time when this place was full of pretty bright people. Now it seems like it's just full of people who want to get in their "You're wrong!" reply without doing any critical thinking.

Re:Microsoft's Official View of the Situation

[joeytmann]

You make a tool/language/framework for developers, you better make it idiot proof.

What's the saying, making something idiot proof and a better idiot comes along?

Re:Microsoft's Official View of the Situation

[techno-vampire]

I hate to sound abusive about this, as I'd only consider myself a mediocre programmer to begin with, but this looks like it rests solely on the programmer who writes shit code.

Never be ashamed of yourself for saying what you think is true! The idea that Microsoft (or any software company) could and should protect us from stupid programmers or is to blame for what's done with their programs is part and parcel of the nanny-state mentality that's doing its best to drag the US into the dirt. This nation was built by people who were willing to take responsibility for their actions and will remain great only as long as we have people like that. Alas, it's more popular today to expect somebody else (anybody else) to take responsibility for your actions and sue them when you're bit by your own stupidity. We were a great nation, once...

Re:Microsoft's Official View of the Situation

[Anonymous Coward]

The fuck are you talking about, you computer hobbyist troll?

You blame the welcome mat company for the door being left unlocked? No? Troll somewhere else.

Oh wait, it's Slashdot. Never mind.

Re:Microsoft's Official View of the Situation

[Impy the Impiuos Imp]

Well, I'll tell you this:

> and is easily defeated by the end user with Firefox and "NoScript"

It should have been even more easily defeated by the end user by doing nothing, by automatic updates.

Re:Microsoft's Official View of the Situation

[Anonymous Coward]

"stupid" yes, "fast" not so much.

The "C is Efficient" Language Fallacy.

Re:Microsoft's Official View of the Situation

[Randolpho]

This is not rocket science here. The 100% certified, no-assembly-required, Makes Baby Jesus Happy (TM) solution to this "problem" is to use your database's built-in programmability feature (better known as stored procedures) every single time you need to pull data push data from your database. No exceptions. And that's it. Stop using lame inline SQL.

I hear even MySQL supports stored procedures now, so I don't see what the problem is, other than millions of lines of sloppy existing code that won't die. But the "fix" has always been there.

Even stored procedures are vulnerable to SQL injection.

The 100% certified, etc., solution is to not use a text-based query language.

Of course, then you lose the massive forms of flexibility that SQL gives you.

Re:Microsoft's Official View of the Situation

[PingPongBoy]

HTML form input straight into a SQL query is so... fucking... bad

Some time ago I wrote a debugging routine to output some info to a browser, and unwittingly output HTML code embedded in the info. Little experiences like that can teach one about vulnerabilities and bizarreness of computers following your every command. FTFA, "little Bobby Tables" is quite illuminating :) and I'm happy to say that all my program-generated SQL queries have always been constructed to treat text as text by escaping single quotes so I didn't become vulnerable to such antics.

Re:Microsoft's Official View of the Situation

[Anonymous Coward]

Wow, you've written 2000 web-enabled forms and they're all SQL injectable? You are part of the problem.

You're right, though. There's no excuse for not escaping your test input. What was yours?

Re:Microsoft's Official View of the Situation

[viljun]

So if you want Microsoft's side of the story, they can't help it that people use bad coding practices. As a coder, I don't agree with that. You make a tool/language/framework for developers, you better make it idiot proof. I agree with MS. Problem is asp-coders have never even heard about coding practices. Just google for a solution for any asp problem and all you find is awful amateurish hacks. And in addition to that often you have no other options than hack. Try to sort a multidimensional array. Hardly possible. Asp doesn't even have a built in command to sort an array - if you can even call them as arrays. Who would still use that old asp? They are surely idiots - including me. And idiots are never experts in security.

Re:Microsoft's Official View of the Situation

[dedazo]

I don't think SPs are painful or intrusive, on the contrary. As long as you keep business logic out of them, they're excellent. Can you do most everything that you can with an SP using parametrized inline SQL? Sure. In my particular niche however (Really Large (TM) Financial Applications), they are a must because of security/audit/management issues.

Re:Microsoft's Official View of the Situation

[nametaken]

Before you go on a rant about how stupid a whole forum of users are, you should be able to demonstrate a reasonable understanding of the topic you're judging people on.

Defining an interface to something like a kernel is one thing, and often still allows for certain kinds of catastrophic failures. Imposing a somewhat drastic limitation on a programmer's data access "by default" (whatever that means) in a feeble, wasted attempt to reduce the likelihood that someone might do something dumb is another thing altogether. Crippling the capabilities of one library and enabling them elsewhere in the same framework would only serve to make a more obscure library the new "default", as you call it.

The combination of proper programming practices, security functions built into the database server and thorough documentation are the appropriate way to prevent stupid vulnerabilities like SQL injection. And let's be honest, it's a terribly silly thing to let happen in your code.

Microsoft has done the only things you could reasonably expect in the way of due diligence by frequently iterating best practices for data access. They've provided abstracted data access controls and binding techniques for people with typical data access requirements. They've even gone so far as to provide data access in larger options like the enterprise library. Anyone who uses unchecked, ad-hoc queries with sqlclient in their codebehind has simply gone out of their way to do something dumb.

All this aside, you've failed to recognize that many other popular web stacks (not just .Net on IIS with MSSQL) allow the same behavior. Consider that this capability might exist for a reason, and that the world may not be comprised entirely of morons who haven't thought things through.

Re:Microsoft's Official View of the Situation

[Sancho]

Before you go on a rant about how stupid a whole forum of users are I said that they didn't do critical thinking, not that they were incapable of it.

you should be able to demonstrate a reasonable understanding of the topic you're judging people on. And I wasn't judging them on database design, I was judging them on nitpicking every last little detail in an effort to sound smart when someone doesn't enumerate every last detail of an idea in a web forum post.

Imposing a somewhat drastic limitation on a programmer's data access "by default" (whatever that means) Do you really not understand what such a thing might mean?

I mean, there are multiple ways to do it. You might set a flag while you're connecting to the database which says, "Allow multiple statements." You might set a flag per-call. You might toggle a setting in the application stack.

Crippling the capabilities of one library and enabling them elsewhere in the same framework would only serve to make a more obscure library the new "default", as you call it. Maybe. Anectodally, I've read through many PHP books, and almost none of them deviate from the default database connection settings until you get into the advanced topics.

As far as your language, I wouldn't call this example crippling. Most OSS projects (again, I can only speak anecdotally of the ones that I've examined) make minimal use of multiple statements. Someone suggested that PHP's MySQL driver now restricts multiple statements unless you set a flag, too.

The combination of proper programming practices, security functions built into the database server and thorough documentation are the appropriate way to prevent stupid vulnerabilities like SQL injection. And let's be honest, it's a terribly silly thing to let happen in your code. We may simply have to agree to disagree. I think that making software safe and secure by default, while allowing people the option to explicitly override that default, is the proper way to go. If someone has to go to the trouble of explicitly allowing unsafe behavior, we may assume that they've at least glanced at the documentation, where hopefully it mentions that this is a really bad thing to do. Note that I'm talking about a general case, here. Multiple statements may not be a really bad thing to do but allowing them is certainly less safe than disallowing them--again, all in the defaults.

Microsoft has done the only things you could reasonably expect in the way of due diligence by frequently iterating best practices for data access. They've provided abstracted data access controls and binding techniques for people with typical data access requirements. They've even gone so far as to provide data access in larger options like the enterprise library. Anyone who uses unchecked, ad-hoc queries with sqlclient in their codebehind has simply gone out of their way to do something dumb. So those half-a-million web application designers went out of their way to do something dumb? This seems to indicate a problem.

All this aside, you've failed to recognize that many other popular web stacks (not just .Net on IIS with MSSQL) allow the same behavior. See, you're just assuming here. I didn't say that other stacks are bullet proof. In other posts, I've noted my dislike for PHP. I'm no Microsoft fanboy--I'm a fan of using the right tool for the job. I'm also a fan of secure-by-default designs--something of which PHP (for example) has a terrible history, as does Microsoft.

Dupe?

[TubeSteak]

500 Thousand MS Web Servers Hacked
Posted by kdawson on Friday April 25, @11:48AM
from the scream-and-shout dept.
http://it.slashdot.org/it/08/04/25/1358234.shtml

Re:Dupe?

[calebt3]

At least this one is more accurate in saying 500,000 web pages and not servers.

Re:Dupe?

[Anonymous Coward]

The article title says "sites", which I think is the same thing. But at least the summary is slightly more accurate

Re:Dupe?

[Cheapy]

/. has been quite good about dupes lately.

I think we can let it slide once and a while.

Re:Dupe?

[pfleming]

You mean IIS can handle more than one site?

Re:Dupe?

[mrbluze]

At least this one is more accurate in saying 500,000 web pages and not servers. Yeah, for a minute I thought this was a veiled attempt at promoting Microsoft IIS as a viable product, suggesting that a lot of people were using it! Ha Ha!

Seems familiar

[EvilGoodGuy]

Wasn't this exact item posted on Friday? http://it.slashdot.org/article.pl?sid=08/04/25/1358234

Re:Seems familiar

[TheRaven64]

Maybe the other editors are filtering out kdawson stories. You should try it, it makes the signal to noise ratio on /. go up a long way.

Dupe

[iamhigh]

Thought you could sneak it by at 5 o'clock, but I caught ya...

http://it.slashdot.org/article.pl?no_d2=1&sid=08/04/25/1358234

Re:Dupe

[eneville]

Nothing gets under your radar.

Just like viruses and worms, slashdot has it's share of dupes. Just like the number of people who posted here to complain that it's a dupe.

Dupe catching on /. has become almost and extreme sport.

Dupe

[Anonymous Coward]

Much?

http://it.slashdot.org/it/08/04/25/1358234.shtml

Dupe?

[Anonymous Coward]

Isn't this a dupe? I remember the same story from a couple of weeks back...?

Wow...

[ActionDesignStudios]

I've seen dupes and all on Slashdot, but this an extreme case. I think this was posted last week, and it wasn't even a good article to begin with. Grats?

How to fix your SQL Injections

[Anonymous Coward]

[quote]
Titus Germanicus writes to tell us that a recent attack has compromised somewhere in the neighborhood of 500,000 pages with a SQL injection attack. The vulnerability seems to be limited to Microsoft's IIS webserver and is easily defeated by the end user with Firefox and "NoScript".
[/quote]

Now, that makes sense. If you have an IIS installation, simply install Firefox and NoScript and you fix all your SQL injections!

Everyone's fault

[ais523]

"is easily defeated by the end user with Firefox and "NoScript"." Well, that protects the end user from the compromised server, but not the compromised server from the compromising script. This is not really a vulnerability in IIS, but it is a design decision that means the compromising script can exploit vulnerabilities in badly-written webapps more easily, so it's slightly Microsoft's fault. It's mostly the fault of all the developers who don't know or don't care about SQL injection, though. The same sort of attack could work against any make of server (because it exploits vulnerabilities in the code running on that server), but would be less easy to automate. And of course, the final end-user-compromising vulnerability has to target the end user, who ought to be protected against malicious websites, but many of who won't be...

Shameless Hibernate Plug

[eldavojohn]

You know, as an incompetent Java developer, I will take the time to explain why none of my web applications suffered from this.

I use Hibernate. I use it with Java, although I know it's now available for .NET.

A feature of Hibernate (aside from some efficient connection pooling and resource management like caching) is that you have to actually call a delete method to delete a row. Something like HibernateSession.delete(myObject); would have to be done. And while this might sound annoying or ruin some tools that are used to generate SQL statements, it protects me time and time again. Now, you can use HQL which is a bastardized version of SQL to generate similar things but, again, I think that you can't drop/delete in it (could be wrong, rarely use it).

Try passing part of an SQL string into an object property and then merge/save it into the HibernateSession. Doesn't do the SQL injection stuff the bad guys want it to. Of course, I still use regular expression common utilities to validate the input, but assuming you didn't do that ...

So why don't other people use Hibernate? Am I missing something about it that's bad?

Re:Shameless Hibernate Plug

[Anonymous Coward]

It's not all that bad but it comes with it's own set of quirks, such as lazy-loading issues and degraded performance. Note I'm not saying it's all bad but as with every abstraction layer it can create it's own problems. I've done quite some consulting for projects which ran into troubles for blindly using Hibernate, just as this post shows problems created by blindly using ASP.Net. Hibernate is not a silver bullet.

Re:Shameless Hibernate Plug

[Anonymous Coward]

Because it onerously bloats application size and complexity, severely degrades performance, and fills the SQL logs with garbage?

Re:Shameless Hibernate Plug

[gazbo]

Because not everyone has swallowed the fashionable BS about ORM being the way ahead, and instead are happy with a pure relational model?

Re:Shameless Hibernate Plug

[ChadAmberg]

Another group in my company is using Hibernate and absolutely hates it with a passion, due to all the bugs they have to work around. The lead architect who doesn't code likes it, but the other architects who still code don't, along with most of the programmers.

Re:Shameless Hibernate Plug

[Cecil]

I can't speak about Hibernate specifically, but I can tell you what my first concern would be. Database frameworks usually tend to have trouble dealing with complex database designs, and if they can deal with them they are invariably much slower and less efficient than a SQL statement could be.

Some of these complexity and efficiency issues can be resolved by partial denormalization of the database design, but again, that introduces inefficiency.

Basically, the use of a high-level framework like that introduces significantly more difficulty into the already difficult problem of performance optimization. And for most people, performance is a more immediate and obvious problem that needs solving as opposed to security.

Another problem in my opinion is that there approximately a million and one different database abstraction layers like Hibernate out there. The lack of standardization makes it very difficult for any of them to gain any sort of critical mass of developers and documentation the way SQL has.

Re:Shameless Hibernate Plug

[Cyberax]

I'm sorry. But what is 'relation model' you're speaking about?

ORM is just another way to work with database. It doesn't magically transform relative database into object database.

Re:Shameless Hibernate Plug

[bottlecaps4u]

I'd like to point out that SQL injection attacks are not limited to IIS web servers. Not properly escaping SQL statements in PHP can lead to SQL injection attacks, and the same problem exists in python, in perl, and in a multitude of languages. Not properly creating limited-access users aggravates the situation as well.

Using Hibernate helps developers by providing a robust persistence layer. But it is important to note the role of this layer -- the persistence layer is simple an abstraction from the underlying SQL. For many software projects, it is a good idea to have a persistence layer since having this layer can provide a measure of protection against SQL injection attacks, but at some point in there code, raw SQL needs to be issued to the database.

It seems to me the point of the article is NOT that SQL injection attacks can occur, but rather MSSQL stored procedures to allow automated attacks scripts to run.

Re:Shameless Hibernate Plug

[Threni]

> I'd like to point out that SQL injection attacks are not limited to IIS web servers.

Shush! Give the Slashdot anti-MS weirdos their two minutes hate. It helps take their mind off the fact that Microsoft's database products are powerful and easy to use.

Re:Shameless Hibernate Plug

[Tim C]

Never mind Hibernate (which is great, but like all tools & frameworks only good as far as it goes and hardly faultless), just use PreparedStatemtents and the setXXX() methods and never worry about SQL injection again. This has been available since JDK1.2 ferchrisakes.

Seriously, the fact that in 2008 any site created by a "professional" web developer is vulnerable to SQL injection is little short of sickening.

Re:Shameless Hibernate Plug

[Anonymous Coward]

SO its better if they didn't allow you to discover the database with sql? (clearly nobody needs that)
Or is it better if they didn't allow you to submit adhoc raw querys to sql?

Up and down this is an luser problem not a microsoft one and it seems everyone with a brain here has already agreed.

Bad code (unescaped /parameterized parameters)
Bad DBA (permissions set so anything can run on the database)
Bad Webmaster (website talking to sql with with to many permissions)

Just because some people can't hold a gun without shooting themselves in the foot doesn't mean you get to take mine away.

Re:Shameless Hibernate Plug

[Anonymous Coward]

You don't even need to use hibernate - just using Java with raw JDBC PreparedStatements (that's a parameterized statement for non-Java folks) protects you fine from injection attacks. I would think most languages have something like this. Who concatenates parameters into SQL strings anymore? Well, I guess at least 500,000 sites do.

Re:Shameless Hibernate Plug

[njcoder]

I agree. Databases are complex for a reason. These tools seem to try and hide this complexity through abstraction. In doing so you lose access to some of the great features of the underlying database, which may be fine if you're using some crippled version of a database, but with more advanced databases you're locking yourself out of some great db features.

Re:Shameless Hibernate Plug

[Sancho]

Some of these complexity and efficiency issues can be resolved by partial denormalization of the database design, but again, that introduces inefficiency. Which efficiency does this reduce? Normally, from a database perspective, normalizing increases data integrity at the expense of database efficiency, doesn't it?

Database frameworks can often deal with complex databases for read operations which, in this day and age, tend to be a high percentage of the operations that a database performs. They're probably worth using for read operations, and write operations where good performance isn't a requirement. You can always fall back on raw SQL (with stringently checked values) in order to gain performance where it's needed.

Re:Shameless Hibernate Plug

[Anonymous Coward]

Now, you can use HQL which is a bastardized version of SQL to generate similar things but, again, I think that you can't drop/delete in it (could be wrong, rarely use it).

There exists an HQL delete statement.

Re:Shameless Hibernate Plug

[Blakey Rat]

The kind of people who write code susceptible to SQL Injection attacks don't read Slashdot, buddy. They don't go to programming classes, they don't read literature, they just do the absolute bare minimum to get by with their VB6 knowledge in the modern world.

Sorry, but that's the reality; anybody on Slashdot already knows what you're saying, and the type of people who code these bugs don't read Slashdot.

Re:Shameless Hibernate Plug

[syousef]

Hibernate has its limitations. I seem to have hit them a few times. Hibernate is great for doing simple things, but if you use any vendor specific features or really complex SQL, you may find yourself falling back to JDBC.

You are completely wrong about drop/delete in HQL. Instead of quoting references you don't have, here's the result of a quick Google search.

http://www.hibernate.org/hib_docs/reference/en/html/batch.html

Your ignorance tells me you have very simple database needs. That's the siutation in which Hibernate will shine.

However, Hibernate can also be rather complex and unintuitive to control. The XML you have to write includes subtle options which need to be set correctly to get expected behaviour. It's very very easy to change an option and completely break a system.

Your smug attitude is awful. You've found a framework that meets your specific needs, but other coders have other needs that aren't met by your pet framework. By the way, I hope you're being paid to plug it, since otherwise you've been brainwashed.

Re:Shameless Hibernate Plug

[rperson]

Hibernate translates directly into SQL. There is even an option to have it print out the generated query so you can see how you messed up your logic. There is even a way to pass in chunks of sql to use features that either have not been implemented yet or are specific to your DB. The reason that systems like Hibernate are not in use more is the perception that they are slow and the urge of programmers to code like they always have and create SQL from concatenated strings.

If you know the theory behind SQL then the two ways of programming Hibernate (HQL and Criteria) are just different typesafe syntaxes.

Re:Shameless Hibernate Plug

[jzuccaro]

If I remember correctly using O/R mapping solutions has an overhead of about 15% in response time. I have no way to sustain that number other than my memory so I will be most pleased if someone corrects me wrong. Nevertheless, compare a 15% in performance drop with all the time saved in development by calling simple methods on an object like "persist" instead of writing whole "insert" SQL statements for a table with 30 fields. For some kind of products that saved time (months?) is far more important than a drop of 15% in response time. O/R mapping solutions are specially good at inserting, deleting, updating and for simple queries like "find all of this kind" or "find by this primary key"... I can tell for my whole experience that this saves tremendous amounts of time, but when you need really complex reading and association of data, like inner joins and stuff like that is when you run into trouble. Thatâ(TM)s the reason why almost all O/R mapping solutions offer ways to use plain old SQL for complex reading queries. The Java people even call this approach a pattern, the "JDBC for reading" pattern.

Re:Shameless Hibernate Plug

[Allador]

You could do this in hibernate as well. Hibernate allows you to run raw sql against the db (in addition to the HQL, you can also send raw SQL).

We've used this in the past where we had to do some fairly extreme performance optimizations for a hideous query across many joined tables, etc etc. The different db platforms required server-specific syntax to get it to perform adequately.

In addition, Hibernate is only avaialbe on Java and .NET.

This particular story is about ASP (not asp.net) pages getting hit, for which hibernate is not available.

Re:Shameless Hibernate Plug

[gazbo]

No, you're right - it combines the worst aspects of both, making something that looks superficially like an ODBMS to the programmer, whilst having none of the features of an ODBMS to make it perform well.

Re:Shameless Hibernate Plug

[Aceticon]

Hibernate actually works best with a properly normalized database.

Performance also tends to be better than hand coded or generated SQL mostly because Hibernate comes loaded with all sorts of database access optimization (read caching, delayed writing, batch fetching, join queries to retrieve multiple related objects, etc) - which would either have to be explicitly implemented or at the very least integrated from multiple utility libraries when not using Hibernate.

The biggest downsides of Hibernate are:
- It works best if the database is designed from the ground up with Hibernate in mind.
- You have to do all sorts of strange things (which negate just about all performance optimizations and even risk application data integrity if you're not careful) to do SQL multiple-row updates or deletes (UPDATE ... WHERE ... / DELETE ... WHERE ...) which in SQL are one-liners.

Re:Shameless Hibernate Plug

[Anonymous Coward]

That sounds like the old "Assembly Language Is More Efficient" canard. Benchmarks have been run on all the major Java database persistance frameworks and the raw SQL JDBC tests clocked in at HALF the performance of the others, just like all those "efficient" assembly bubble sorts (the only sort you can easily code and debug in a day) got blown away by Heap and QuickSorts that could be more rapidly implemented in high-level languages.

As for the proliferation of standards, that's on the way out as the Java Persistence Architecture (JPA) provides a unified API for EJB, JDO and Hibernate.

Re:Shameless Hibernate Plug

[Anonymous Coward]

A feature of Hibernate (aside from some efficient connection pooling and resource management like caching) is that you have to actually call a delete method to delete a row.

Chapter 13, hibernate manual:

Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();

String hqlDelete = "delete Customer c where c.name = :oldName"; // or String hqlDelete = "delete Customer where name = :oldName";
int deletedEntities = s.createQuery( hqlDelete ) .setString( "oldName", oldName ) .executeUpdate();
tx.commit();
session.close(); If "oldName" wasn't used, and instead, it was just concatenated on to the end of the string, then SQL Injection attack is possible. Doing it your way means that batch deletes take *forever* because you're doing them one at a time.

Use of HQL is an amazing (and IMHO the best) way of using hibernate. If you're not using it that way, you're missing out - and coming to the reason people don't use it.

Using it strictly using the OOP way, it takes longer to write code for it, and the code runs slower than if you just use pure SQL for most usages (because it has to fetch a good deal more than you normally would). The performance gains from caching make up for this in some environments, but not most.

You have to actually use Hibernate's advanced features to start saving time.

Re:Shameless Hibernate Plug

[Anonymous Coward]

I work primarily in .NET in my day job. None of my web apps suffer from this either, and I use SQL Server extensively.

First off, queries in code are a) hard to maintain, b) hard to debug, and c) frequently vulnerable to SQL injection. So use stored procedures. There are two comebacks to what I've just said, and I'm going to shut them both down.

1) "Queries in code are only vulnerable if you inject form input into them." - True, but if you're not the only developer working on the project, there's a chance some dimwit you work with will come along and modify things to the detriment of the entire system.

2) "Stored procedures are slow and/or hard-to-make." - No they're not. They're faster than a one-off query since they're pre-parsed (and all queries in code are one-off, repeated or not). They're also quite easy to make in SQL Server, and probably just as easy in every other DBMS. "CREATE PROCEDURE" is your friend.

But that's just the general problem I see with most of the whining in this topic.

As for Hibernate/NHibernate, well, it's way easier to "roll your own" data object framework, and it can be kept much lighter-weight than the all-purpose Hibernate library. This leads to fewer performance problems, better understanding of database code, and flexibility only where you need it, not everywhere (where Hibernate has to put it, since it's general purpose).

Another benefit specifically for .NET is that you can build either with an ORM framework, or you can use the ADO bindings. And this can be decided on a control-by-control basis. You may bind a GridView to a hard-coded DataSource, but when saving data in a postback, you use your ORM classes to do the heavy lifting. A hybrid approach can increase flexibility and cut maintenance headaches at the same time.

Re:Shameless Hibernate Plug

[Cyberax]

Have you even worked with good ORMs?

Hibernate performs quite well, it doesn't try to mask the underlying database. HQL (Hibernate Query Language) is just SQL with some additional nice features AND you can use native SQL without any problems.

Re:Shameless Hibernate Plug

[gazbo]

Honestly, no - I've never used Hibernate in particular. However, my job involves not only the usual simple persistance/retrieval stuff (which ORM makes easy) but also writing complex reports (or even not-so-complex reports that just really don't fit the OO view of the data).

As you point out, a good ORM framework will allow you to query this anyway, but the problem there is you're not reading my posts in the context of the OP. I'm not denying ORM has its uses (that would be retarded; by definition it's needed in some form if you want to use an OO program with a relational backend) but the OP was asking why anyone would access a DB with anything other than an ORM framework - and the answer is that sometimes the query you run just doesn't cleanly fit the OO model you've constructed.

Your pragmatic comment that "you can use native SQL" rather negates the OP's point. If you're using native SQL then the fact you're using Hibernate is irrelevant; you could be using any DB interface that supports prepared statements (or otherwise parametised queries) and there I would have to agree that in virtually all cases you really should.

Actually, the more I think about it, the more I suspect we're not even at odds here. I've nothing against using ORM frameworks to interface between OO code and an RDBMS, and your comment about HQL/SQL suggests you've nothing against leaving the application-specific object model in order to retrieve datasets that don't fit it. My argument is with this strange dogmatism that seems too common at the moment, that OO is always good and everything else is always bad. Once again, the concept of "right tools for the job" is seen as heresey.

Re:Shameless Hibernate Plug

[Cyberax]

Honestly, no - I've never used Hibernate in particular. However, my job involves not only the usual simple persistance/retrieval stuff (which ORM makes easy) but also writing complex reports (or even not-so-complex reports that just really don't fit the OO view of the data). We write pretty complex reports using HQL and Hibernate, there's no problem with relational model at all. In fact, ER-diagrams used to model relational databases map PERFECTLY into object model.

Instead, problems begin when relational model is not enough and you have to use non-relational extensions of your database or things like views and triggers (which are orthogonal to relational databases theory).

...the OP was asking why anyone would access a DB with anything other than an ORM framework - and the answer is that sometimes the query you run just doesn't cleanly fit the OO model you've constructed. Parent, clearly, has not worked much with complex data processing. However, he has a point - most applications do not even NEED complex data processing.

Most PHP websites just use scores of "select ... from ... where id=234" which can be automated by Hibernate.

I mostly agree with the rest of your reply.

Re:Shameless Hibernate Plug

[Tablizer]

A feature of Hibernate (aside from some efficient connection pooling and resource management like caching) is that you have to actually call a delete method to delete a row.

Another way to get the same thing is to create different access names (such as ODBC connections) with read-only, update-only, deletable, etc. That way even if altering SQL commands gets through, the SQL is only executed with the relevant permissions. (Of course, it won't stop "bad" reading by itself, but it's an extra measure.)

Re:Shameless Hibernate Plug

[Baki]

Then they should learn to use it. I've been using it for 3 years in a very complex online application with heavy batch processing as well and extreme performance requirements (to generate stock exchange orders for several 100-thousands of customers, i.e. a highly critical application as well). I have found 2 real bugs in those three years, and I can tell you we used each and every feature of hibernate and used it to the max.

After a while of course I know hibernate and its internal structure/code inside out. It is not easy, one should not use hibernate with the idea to hide oneself from sql or the complexities of the database. In fact, the hibernate developers recommend you should be a database expert and always check the generated sql, this is not a tool for DB ignorant java developers to be able to use a database.

When used correctly, it is a huge time saver and also saves a lot of manual and tedious coding.

We used the "man in the middle approach" where one makes an OO design and a DB design and then maps the two using hibernate mappings. We were able to map a wide variety. If one sticks to sound DB design principles (such as normalization, using surrogate keys everywhere) the mappings work very well and without much tricks.

Hibernates excellent caching and use of prepared statements provides very good performance. One can fine-tune the amount of data loaded and how it is kept in memory or overflows to (fast) disk hash files very well. It would be almost impossible to reach such performance by manually coding everything, at least it would cost much more time without much extra performance.

This application is used internally only and has been running for 3 years now without any flaws in the crucial parts.

There have been some suspicions for bugs in hibernate, in each case I was able to demonstrate that this was due to the developers incompetence and was due to wrong usage and/or not reading the consize manual of hibernate.

By the way, I hate and do not trust architects that don't code. Someone must bridge the gap, the architect must be able to code and thus give the right example to the rest. I am a software architect myself but always need to do enough hands-on developing myself.

Re:Shameless Hibernate Plug

[gazbo]

Just one nitpick - stored procedures are not always faster, and for much the same reason: as they're pre-parsed and planned (which is the time-saving part) the query planner can make no use of the actual parameters when deciding the optimal plan. I have found (admittedly rarely) that turning a literal query into a stored procedure can increase the run time of the query several times over.

Dupe Dance

[jd]

Yay! We get a re-run of one of the more non-story events of recent times. The problem was spotted very quickly by IIS admins, as was noted before, and it's half a millon pages, not half a million sites. Well, unless all sites have one page and I've only been thinking they used hypertext links to more of their own content. It's unclear what percent of those sites were IIS, what were Apache (an easy server to misconfigure), and what were other web servers. Blaming it on IIS is easy, and there probably is some truth to the allegation that IIS has flaws when it comes to SQL support, but this time they almost (I said almost) have justification in crying foul when Microsoft gets blamed.

What I don't get, though, is not only does this dupe the earlier story, it dupes ALL OF THE ERRORS as well. Sheesh!

Re:Dupe Dance

[pavera]

Wrong. This story is not the same one linked before, and it actually explains why this is an MS only problem (not all SQL injections just this one).

It is not an IIS problem it is a MS SQL Server "feature" whereby you can basically create a dynamic query that will go figure out your database schema for you, and dynamically perform updates on the table. This is not possible against Oracle, MySQL, or PostgreSQL, but MS SQL allows you to create a single query that can successfully attack any MS SQL database.

Usually SQL injection attacks are pretty extremely customized, because they have to deduce the database structure so that they can create a valid update query to insert the malicious code into the DB. This MS SQL feature allows you to automate the attack.

Still it is not MS's fault, but it is only affecting MS SQL server backed sites, and there are ways to secure your DB so this attack fails (so blame the DBAs first), second blame the web developers.

Had a problem once..

[thewils]

...with a user wanting to inject images from other websites into my pages.
I solved it quite nicely by translating any opening bracket to "ampersand-gt-;" (you know what I mean) and any urls were totally ignored after that.

It's a well known bug in IIS.

[dameron]

A buffer overflow in the dupcheck module leads to privilege elevation.

You can spot if pretty easily if you reload a backup from 4/25 and your web page keeps spamming out the same offensive links.

How does Apache avoid this?

[hellfire]

I'm not knowledgeable to answer this, but I know there has to be a good "in your face, Microsoft" reason why this doesn't hit servers like Apache? They point the finger at the websites and say "UR DOIN IT RONG!" and blame them. And yet, apache users don't have to worry about this. Why? That's the argument I want to have.

Re:How does Apache avoid this?

[Anonymous Coward]

Because it's a Microsoft product, and hence must be the root of all evil. Let's disregard how stupid the website developer is for not sanitizing SQL queries and blame MS instead!

Re:How does Apache avoid this?

[graveyhead]

No such "in your face" reason exists. It's not Apache that matters here (or IIS I'm guessing), it's the database and interacting with it via some server side language.

So when someone appends a string to a query directly from a CGI variable (in an URL, after a questionmark - those are CGI vars ... blah.cgi?bar=baz) this can be used as an attack vector regardless of the platform. This error is super easy to make in PHP for example:

mysql_query('SELECT * FROM mytable WHERE foo = " . $_REQUEST['foo']);

What's happening here is that the user value for "foo" is being used as the WHERE clause of a SQL query. Looks nice and innocent, right?

Well, guess what if someone hits your site with this:

blah.cgi?foo=(DELETE FROM MYTABLE)

Result: byebye database.

Fixing this is known as "sanitizing inputs" and there's many ways to do it.

What this IIS thing sounds like to me is some specific application that happens to use IIS / MSSQL does not sanitize. Therefore vulnerable.

Re:How does Apache avoid this?

[mingot]

Not really because apache is just as susceptible to this as any other web server.

Re:How does Apache avoid this?

[jd]

People have done SQL Injection attacks on Apache servers and probably most other servers. It seems as though this flaw is made easier on a misconfigured server, but you can misconfigure any software that uses a configuration file. It's easiest when the configuration isn't validated correctly, or when it's impossible to determine all invalid cases, or when a case may be invalid only under certan circumstances. All of these are bound to crop up on something like Apache.

Besides, there must be bugs elsewhere, or the article writer wouldn't have repeated an already-corrected folly of confusing pages with servers.

Re:How does Apache avoid this?

[Foofoobar]

Simple answer. mysql_real_escape_string. Instead of sanitizing data through the language which will miss byte encoded strings, alot of applications have switched to using MySQLs native mysql_real_escape_string which will catch these. Java sanitizes byte code strings as well I believe.

So it may be partially C# or just that Microsoft web devs are inherently 'dumber'.

Re:How does Apache avoid this?

[blowdart]

A mild correction; no-one runs a SQL injection attack against a web server, it's against the software that runs on that web server. So strictly no-one runs a SQL injection attack against apache, apache by default does not use any sql database; it's the same situation with IIS.

Re:How does Apache avoid this?

[Joe U]

Because the automated injection script was written for asp/asp.net and Apache rarely uses asp or asp.net.

Please scan your news sites for past and future php scripts if it makes you feel any better.

Re:How does Apache avoid this?

[Anonymous Coward]

The exploit depends on a chunk of SQL that targets only Microsoft SQL Server. The slashdot "editors" think this is an IIS exploit because they don't know that IIS and MS SQL Server are two different products.

If someone wrote a generic script that targetted MySQL, I'm sure the idiots at Slashdot would post an article about a security hole in PHP.

Re:How does Apache avoid this?

[blowdart]

asp.net sanitises by default; in fact it won't let certain strings be submitted as part of a form to protect against XSS. you have to specifically turn that off. c# also provides parametrised queries specifically to escape strings properly with any .net data provider.

A belief in the superiority of php developers isn't helpful, nor is it correct. I give a bunch of talks each year on this very topic and the amount of shocked php developers is pretty much the same as the amount of shocked asp.net developers. Part of the problem is no school teaches this stuff; security does not seem to be a part of any degree course I've encountered. Part of it is that the basic teach yourself books don't cover it either; asp.net/php for dummies will not list it, and database texts certainly don't, as it's not part of their domain. WordPress, Movable Type, Joomla! have all had SQL injection problems; Oracle has a great one right now which is a database level problem which defensive coding may not even catch to do with date parsing. It's not a question of one platform's developers being dumber, it's because no-one has ever warned them.

Re:How does Apache avoid this?

[Anonymous Coward]

Oh good lord... 1998 called, and they want their bad ideas back.

Just use prepared statements, like every other decent developer in the world. Or even better, use stored procedures exclusively, and don't give your web stack insert, update, select, or delete permissions on your database.

Re:How does Apache avoid this?

[Sancho]

That's close.

http://hackademix.net/2008/04/26/mass-attack-faq/#comment-7742 has a decent explanation of why this is primarily hitting IIS. SQL injection is common to many platforms, but Microsoft's database driver has some features that made it particularly easy to generalize the exploit. Specifically, prior knowledge of the table layout was apparently unnecessary to create the exploit, meaning that it was easy to hit a large number of websites in a short period of time.

Re:How does Apache avoid this?

[cliveholloway]

There are two parts to this:

- no untainting of CGI data
- bad DB interaction practices

Now, I don't do ASP, so I'm unaware of the exact details, but in Perl (and any CGI language), it's always insane NOT to untaint your input submitted by users - even if (especially if!) you have set the values in hidden fields. Something like

my $id=0; # $id must be an integer under 100
$q->param('id') =~ /^(\d{1,2})$/
        and $id = $1;


And, as to the SQL injection itself, if ASP doesn't have placeholders, I would blame MicroSoft. Interpolating fields into DB statements is just asking for trouble.

Re:How does Apache avoid this?

[Foofoobar]

PHP developers? Ha! The vast majority of them would ruin us all. It's just that having worked in heterogenous shops and monogomous shops (always all Microsoft), Linux people understand protocols and multiple platforms and undecstand what they are doing and the underlying mechanics far better than their Microsoft counterparts; Linux people can learn Microsoft technologies but Microsoft people freezeup, freakout and panic when they have to work with an open protocol or something not handled for them by Microsoft.

Re:How does Apache avoid this?

[Foofoobar]

Well if PHP had a decent way to do prepared statements like JAVA, I'd say 'hallelujah brother'. But they don't... and the current methodology allows for the same error of byte code strings to be entered. Which is why you have to use mysql_real_escape_string to avoid byte code strings being used for sql injection.

JAVA on the other hand is far more prepared (no pun intended) for this.

Re:How does Apache avoid this?

[fortyonejb]

fanboy posting at its best. Yes, your experience speaks for everyone. I make my bread and butter off of MS tech, but I do just fine with anything non-MS. Don't try and speak for all of us.

Re:How does Apache avoid this?

[Foofoobar]

You're the exception that proves the rule.

Re:How does Apache avoid this?

[ralphdaugherty]

And yet, apache users don't have to worry about this. Why? That's the argument I want to have.

Because the likely first step is bad guys in China scanning Google search results for web pages ending in .asp or .aspx. They then retrieve the pages and fill in forms with an SQL statement containing javascript code as a string and submit the page. All of this is automated.

In this case, it's SQL Server specific SQL syntax that retrieves field layouts for the database, then inserts thia attacker's javascript string into *every* text database field that will hold it in the entire database. Holy cow.

Then any page whatsoever that retrieves any data from the database and displays it in a web page will pull the javascript along with the data and execute it after showing the data. That javascript then downloads malware from a specified Chinese site to the PC.

Game over.

Re:How does Apache avoid this?

[Allador]

And, as to the SQL injection itself, if ASP doesn't have placeholders, I would blame MicroSoft. Interpolating fields into DB statements is just asking for trouble. Using ASP/ADO/MSSQL there are several ways to protect against this.

1. Use prepared statements (also sometimes called parameterized queries, and what you're calling placeholders).

2. Use stored procedures and pass parameters.

3. Clean the form fields before putting them into your sql statement (the php approach, and also the least safe).

Re:How does Apache avoid this?

[Anonymous Coward]

Well if PHP had a decent way to do prepared statements like JAVA, I'd say 'hallelujah brother'. Ever heard of PDO?

Article

[bobwrit]

I found this article on why microsoft won't exsist for much longer. It's at http://comprog.freeforums.org/why-microsoft-will-not-exsist-for-much-longer-t31.html/

FF fanboi?

[Anonymous Coward]

So... a server side exploit is "defeated" with a client side browser + extension.

In case you go to a malicious site that makes you SQL exploit a 3rd party site?

Re:FF fanboi?

[Anonymous Coward]

FTFA:

The attack itself injects some malicious JavaScript code into every text field in your database, the Javascript then loads an external script that can compromise a user's PC.

Bad Language makes Bad Programs

[MarcAuslander]

Bad language leads to bad programs. Classic example - C doesn't associate lengths with strings or arrays - and buffer overflows result. A SQL interface that requires/allows constructing strings which mix syntax and user data is asking for trouble. You can blame the programmer for not validating the input data - but unless you provide the validation tool, its still your fault - you the language designer.

Re:Bad Language makes Bad Programs

[ForumTroll]

Bad programmers write bad code despite the language. I don't want to use a language that places a ridiculous number of restrictions on me merely because someone somewhere might find a way to fuck up. Furthermore, validating input is a library problem not a language problem, and practically every language has libraries for escaping input. Nobody is to blame but the developers of the project being exploited.

Re:Bad Language makes Bad Programs

[Wrath0fb0b]

Bad language leads to bad programs. Classic example - C doesn't associate lengths with strings or arrays - and buffer overflows result. A SQL interface that requires/allows constructing strings which mix syntax and user data is asking for trouble. You can blame the programmer for not validating the input data - but unless you provide the validation tool, its still your fault - you the language designer. Rubbish! You can have my C-style arrays when you pry them from my cold dead hands because, for my particular purpose, I don't need every access to check the bounds of the arrays. Please stop attempting to have the language force me to use the coding conventions that you prefer - the language should provide both safe and unsafe array access. This is the beauty of the C++ STL Vector class: it provides all the tools without judgment.

Let's take a stupidly simple example -- I want to write a function that returns the sum of a vector
template
inline T sum(const vector &lt T &gt &v) {
        T _sum = 0;
        for(unsigned i = 0, s = v.size(); i &lt s; ++i)
                _sum += v[i]; // NO NEED TO CHECK 'i' -- GUARANTEED TO BE IN BOUNDS //
        return _sum;
}
Sorry, Java users, your language specification will not allow you to access an array without a bounds-check (see the Java Language Spec, http://java.sun.com/docs/books/jls/third_edition/html/arrays.html#10.4). You are just SOL. I did a quick test summing up 10000000 random integers using the code above, and an identical version using vector.at() which does bounds-checking. The performance difference was greater than 3 times.

Here's the code if you don't believe me:

APPENDIX:

#include &lt iostream &gt
#include &lt vector &gt
#include &lt ctime &gt

using namespace std;

template &lt class T &gt
inline T sum_fast(const vector &lt T &gt &v) {
        T sum = 0;
        for(unsigned i = 0, s = v.size(); i &lt s; ++i)
                sum += v[i];
        return sum;
}

template &lt class T &gt
inline T sum_slow(const vector &lt T> &gt v) {
        T sum = 0;
        for(unsigned i = 0, s = v.size(); i &lt s; ++i)
                sum += v.at(i);
        return sum;
}

int main(void) {
        vector &lt int &gt a(10000000);
        for(unsigned i = 0, s = a.size(); i &lt s; ++i)
                a[i] = rand();

        clock_t start1 = clock();
        int res1 = sum_fast(a);
        clock_t end1 = clock();
        cout &lt&lt res1 &lt&lt " computed in " &lt&lt end1 - start1 &lt&lt " cycles\n";

        clock_t start2 = clock();
        int res2 = sum_slow(a);
        clock_t end2 = clock();
        cout &lt&lt res2 &lt&lt " computed in " &lt&lt end2 - start2 &lt&lt " cycles\n";
}
Produces the following output (MSVC 2K5 EE, all optimizations on)
614261309 computed in 15 cycles
614261309 computed in 47 cycles

Re:Bad Language makes Bad Programs

[Jaime2]

but unless you provide the validation tool, its still your fault - you the language designer I'll bet 90% of the coding errors were done by developers who said "I hate those Visual Studio wizards Microsoft has for data access. I can do it better myself." Sure, the wizards aren't the best way to build an application, but at least they prevent SQL injection. I meet these people every day... they think they know a lot about programming, but really they are people with 20 years of experience just barely making applications work and developing more and more bad practices every day.

It's fine to reject the tools you are given. But if you reject them, at least have a better plan. ASP.Net has easy to use form validation tools, easy to use SQL injection preventing GUI data access tools, and easy to use base classes that prevent SQL injection. The people who made these problems avoided using about twenty tools at their disposal for avoiding this class of bug. This is certainly not Microsoft's fault.

Re:Bad Language makes Bad Programs

[XMyth]

Microsoft is working towards eliminating the root of this problem (the problem being tunneled languages like SQL) with the addition of LINQ to .NET.

Re:Bad Language makes Bad Programs

[TheRaven64]

So, you're saying you don't want a language feature because your compiler sucks? In your example, the range of i is known at compile time and so a good compiler would pull the test out of the loop and only do it once. An experimental Java compiler being developed at IBM goes one step further and defines set-theory operations on index sets allowing you to perform all of your bounds checking at compile time and giving no runtime overhead. In their tests, there was no performance difference between this and the version with bound checking completely disabled.

Re:Bad Language makes Bad Programs

[Wrath0fb0b]

Quote the Java Specification (link in parent):

All array accesses are checked at run time; an attempt to use an index that is less than zero or greater than or equal to the length of the array causes an ArrayIndexOutOfBoundsException to be thrown. What you have described simply cannot be done.

Why can't they block/blacklist domains?

[stun]

Why can't they (the big guys) create an "Internet Police" to blacklist
certain domains from the Internet that are spreading those malwares?

I have read the news that some people have been working on finding out sites with malware on it using Google.

1. Have the "Internet Police" contact the Web Admin of the "offending" site to clean up their own server.
2. If they don't clean it up after a certain time, stop performing the DNS.

Ok, I *do* realize that this is really difficult and comes with crapload of legal and drama issues,
but I say we have to start from somewhere to take action on this.

And of course, some countries make it difficult (if not impossible)
to track down those malware spreaders *coughRussiacoughForExample* http://www.technewsworld.com/story/33127.html?welcome=1209421471/
and http://www.technewsworld.com/story/Researchers-Shed-Light-on-Shadowy-Russian-Botnets-60640.html/.

Now I say "Fuck those Russian bastards and their corrupted government and law enforcement agencies."

Re:Shameless ORM Bashing

[Foofoobar]

Yeah and ORM loads more data than you will need or use in comparison to a properly formed query moved to a separate db layer which has all the benefits of ORM with none of the bloat.

Coldfusion Anyone?

[oni]

Has anyone ever heard of a SQL injection vulnerability in a Coldfusion app? I know some smartass is going to say, "that's because nobody uses it" but that's not true. If there are a million ASP apps out there and 500,000 SQL injection vulnerabilities, then there have to be at least 100,000 coldfusion sites. Show me the 50,000 coldfusion SQL injections. Or show me 10,000, or 5,000 or even just 1.

I have some experience with coldfusion and it is my opinion that a SQL injection vulnerability is pretty difficult to create even when you intend to create one. The reason is because, unlike every other language (java, ruby, PHP, etc.) coldfusion doesn't have this idea that you take any old random string and pass it off to the ODBC. Instead, you build the query inside special tags, and the interpreter can keep an eye out for errant quotes.

a SQL injection vulnerability in coldfusion will involve a special function, preserveSingleQuotes() that you only need in very rare circumstances.

So maybe everyone should switch to a safer language, eh?

Re:Coldfusion Anyone?

[S'harien]

ColdFusion is most certainly vulnerable to SQL injection if you are not religiously using the CFQUERYPARAM tag inside your queries. Of course the database being queried needs to support multiple SQL statements in a single query (MySQL does, Access does not, can't speak for any others). http://www.adobe.com/devnet/coldfusion/articles/cfqueryparam.html

Re:Coldfusion Anyone?

[isorox]

Instead, you build the query inside special tags, and the interpreter can keep an eye out for errant quotes.

It's called a prepared statement

Re:Coldfusion Anyone?

[Anonymous Coward]

ColdFusion is no more invulnerable to SQL injection than any other language and/or framework. The *only* thing it has in place by default is that beginning with CF6, single quotes were auto-escaped when used with cfquery unless PreserveSingleQuotes() is used then it's not even of any value there. That said; any injection attack that does not require the use of single quotes (e.g. an integer-based attack) will succeed without an aftermarket mitigation strategy in place (e.g. paramaterized queries, manually input validation or stored procs).

Re:Coldfusion Anyone?

[CodeBuster]

I have some experience with coldfusion coldfusion is dead or dying. You are the first person that I have heard mention it in years. If people are going to choose a proprietary solution for their web application server needs then they generally choose IIS with ASP.NET; otherwise the choice is probably PHP on Apache or Ruby on Rails.

So maybe everyone should switch to a safer language, eh? The problem here is not the language it is the use of that language in ways that are specifically warned against as being dangerous. The power to create complex applications brings with it the possibility of self-destruction. The addition of power tools to your wood shop can expand productivity and open up new types of projects which were previously unavailable to you. On the other hand, you have to be careful with that circular saw or you might loose a few fingers. Power and complexity vs safety and simplicity but with limitations are trade offs that every developer must make.

Re:Coldfusion Anyone?

[kiddygrinder]

nice idea, but i think the problem is more people doing things on the cheap instead of getting a real web dev so i don't think telling people to spend a large chunk of cash on coldfusion is going to fix it.

Re:Coldfusion Anyone?

[Sancho]

If I were guessing, I'd say that Coldfusion has a fairly low market share. The main reason that I'd say this is that it's a) an expensive solution that b) isn't Microsoft.

Lots of people pick free solutions. Lots of people who don't pick free solutions know about IIS and MS SQL. They stick with Microsoft because it's the brand, and it's a one-stop shop for support. There are also a lot more VBS/.Net developers than Coldfusion ones, so developers will be cheaper.

That said, there are 38,000 hits from Google for coldfusion sql injection. Most of the hits in the first few pages aren't talking about how Coldfusion is magically immune. While that doesn't mean that it isn't, I know where I'd lay my money if I were a betting man.

Re:Coldfusion Anyone?

[XMyth]

I'd rather eat cat vomit than write web apps with ColdFusion.

Thanks for the suggestion though.

Re:Coldfusion Anyone?

[oni]

coldfusion is dead or dying.

LOL. I guess you're the netcraft bot. Languages don't live or die based on what a bunch of fanboys with no actual programming skill put on their resume. **everybody** claims that know C++ but very few people do. By contrast, **nobody** bothers to put coldfusion on their resume unless they actually have experience with it. In other words, the numbers for the sexy (meaning, talked about on slashdot) languages are way over inflated, and the numbers for other languages are actually more accurate. Coldfusion is dying the way Linux is dying - in other words, just because you personally can go your whole day in a microsoft shop hearing about how awesome windows is, that doesn't mean that linux doesn't exist or isn't superior.

This is typical for a dupe

[panaceaa]

Actually, most dupes on Slashdot are a couple days apart like this one. After that they fail to be news and tend not to get reposted.

The extreme cases are actually measured in the years or hours. There's multiple cases of an article being duped 2-3 years later, especially when they're industry studies on how people use technology or occasionally about scientific discoveries. For the latter, it's often that a university announces they've done something and then publishes the results, which results in two very similar though arguably non-duplicative Slashdot articles.

On the other side, sometimes there's big news and an editor decides to get it out fast without reading the current front page. I've seen dupes within the same hour, but more likely they're 2-3 articles apart in the worst cases. This was one of the arguments for introducing the Slashdot subscription model, in fact: Subscribers have early access to upcoming articles and can tell editors that an upcoming article is a dupe. In many cases (but not all) the editor pulls the dupe before it gets pushed to the front page.

Re:This is typical for a dupe

[sootman]

I'd be extremely impressed if someone could get a story approved that started with "Slashdot reports that..."

Same Security Measures Apply Since 1996

[Anonymous Coward]

Hey, um, the same security guidelines for working with SQL code and various languages hasn't changed in over a decade guys... c'mon, this is really a pathetic takeover of the industry with people with the strongest immune systems and worst hygiene.

*puts on safety glasses*

Bogus dupe of bogus story

[Anonymous Coward]

It's not. The summary is bogus, just like when it was when it got posted last week.

Comment removed

[account_deleted]

Comment removed based on user account deletion

LINQ/SQL and ADO.NET ENTITY FRAMEWORK

[Anonymous Coward]

Aside from Hibernate ( which is ok ) there is LINQ (for SQL) and the ADO Entity Framework. Both are from MS and both are pretty good. The framework is in CTP and a few features are missing but I've tested the existing feature set under load and found it useful, solid, and the performance ok for not SQL Direct. LINQ is in production.

http://en.wikipedia.org/wiki/Language_integrated_query [see LINQ for SQL down the page]
http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework

I think Hibernate (for Java) is pretty good, easy to use. I found some of the problem a pain (the old compound key thing irked me). But it is suprising home many people don't like it anymore.

Quicky Question

[udippel]

From what I understand from just flippering through the summary,
The attack itself injects some malicious JavaScript code into every text field in your database, the Javascript then loads an external script that can compromise a user's PC
the infection requires that a local user on that database box browses the net, and hits a malicious site?

I really wonder, if users on database-running PC are supposed to browse the net, for pr0n, or what?

Am I correct that my fictitious boxen are free from danger, if I have no local losers' accounts for surfing?

Re:Quicky Question

[cervo]

I think you misunderstand the article. The attack injects javascript code into the text fields of the database. The attack is done by someone exploiting SQL injection on the website. Nothing to do with a web surfing account on the database computer. The attack inserts Javascript into every text field. If it was a message forum, this might be the from fields of an e-mail, the message text of posts, the subject fields of posts, etc.... Regular users using the forum are suddenly exposed to the javascript.

Re:Quicky Question

[UnknowingFool]

From my understanding, most sites employ a generic user for the db side of the things. The tricky part has to do with escape characters.

In my simple pseudo-example, I visit a shoe company site, ABC Shoes. They have a nifty product catalog search. As a hacker, I notice that the url string to search for green shoes contains: "select product_name from products where color='green'". I can change the url string to: "select product_name from products where color='green'; truncate users; insert into users (username, password), values ('me','abc123'); grant all on * to me" The last part is what is known as SQL injection. Three commands were sent to the database after the simple search command. One of them clears the entire users table and the second one inserts a new user. The third command grants my new user all rights. I now have control of the database and can possibly infect anyone visiting the site by uploading a virus, trojan, etc. To other users, they visited a legitimate and benign website (ABC Shoes).

To be clear, many databases are vulnerable to SQL Injection. Why MS IIS sites were affected by the last attack was that the attack may have been specifically made for MS SQL Server. After all, commands and the structures of system databases are different from database to database. If the website developer had prepared for this, he should have it in the code somewhere to ignore the last three commands by ignoring escape characters. I think also if the generic website db user had restricted rights that might help. But restrict the rights too far and the website can't function.

Re:Quicky Question

[Anonymous Coward]

this has been known for a long, and I mean a very long time. people have been injecting scripts through forms for a long time now. I can't say long time enough. The problem is usually fixed by using error commands and setting limits to how the data is handled. It's fairly common. If a programmer doesn't know this then they are doomed for lawsuits.

Again

[isorox]

Wow, that's awful, so soon after the last issue?

little-bobby-tables-strikes-again dept

[cyberstealth1024]

from the little-bobby-tables-strikes-again dept. Awesome xkcd reference! http://xkcd.com/327/

The only story here...

[NullProg]

Is that Linux, BSD, Sun, AIX, and whatever are just as vulnerable when it comes to dumb programmers.

The million dollar question is what platform and which web server is it easier to reinstall to get the site back up.
I think Linux and BSD have the advantage.

Enjoy,

Re:The only story here...

[Skapare]

Is that Linux, BSD, Sun, AIX, and whatever are just as vulnerable when it comes to dumb programmers.

The million dollar question is what platform and which web server is it easier to reinstall to get the site back up.
I think Linux and BSD have the advantage.

Actually, the damage is to the database. The fix is to restore from a backup taken from before the attack, resyncronize with records sanitized for the inserted bad data, fix the vulnerable code, and bring the database and web application back up.

In related news...

[gmuslera]

Half a Millon Slashdot-Powered Stories Hit with Dupe Injection

Re:Shameless ORM Bashing

[Anonymous Coward]

Hibernate supports lazy loading in which case you can specify exactly what it has to load up front and then if you need more stuff later it will load it then.

There's problems with that approach as well, but it largely eliminates the bloat problem.

As a complete aside, I don't believe hibernate sanitizes inputs for you, so it's still possible to perform injection attacks on it

They do this to all sites.

[Neanderthal Ninny]

I don't have any MS SQLServers here at my site so I block all sqlserver request and my firewall gets hit with thousands of sqlserver hits everyday. I think they have bots that go out an scour the network for any sqlserver regardless they exist or not. Once they find a sqlserver then they pounce on it with a vengeance.

Scripted ASP or Poor Design Patterns

[ScotlynHatt]

What you are saying is a sound argument. There are many design patterns that protect you from these kind of issues and also improve the maintainability of your application. This attack is successful because people are either creating ASP pages with DB access coded right in or are not following a design pattern that abstracts the DB access from the UI/Controller/Service layer in a way that makes SQL injection much easier to programatically test and defend against. At the end of the day they are using IIS and MS SQL Server, which shows bad judgment at the outset.

Re: SQL Server vulnerability

[butlerm]

The problem is not SQL Server's support of multiple statements, but rather the way they do it. Oracle supports multiple statements, but only in a PL/SQL begin end block, which is generally speaking impossible to inject.

SQL Server on the other hand is trivially exploitable if any parameter is unchecked, due to the way statements are chained together - no block syntax required, just a semicolon and anything goes after that.

Re:Shameless ORM Bashing

[Anonymous Coward]

+1

but then again, he did say he was an incompetent java developer. So everything you just said is way over his head.

This is NOT an IIS problem

[ShaunC]

The exploit in question has nothing to do with IIS, period, whatsoever. It's being targeted at servers that run IIS because those are the ones most likely to have SQL Server as their database back-end. Plenty of companies have deployed a Linux/Apache/PHP stack that talks to a SQL Server backend via FreeTDS, for example, and some of them will be getting hit by this, despite not running a single instance of IIS.

The query being used is exploiting features in Microsoft SQL Server, combined with a couple of external factors. Developers who have failed to check and sanitize user input, and DBAs who have not properly secured their databases. In order for your website to be owned through this attack:

1. You must be running Microsoft SQL Server as your database platform
2. Your web application must be vulnerable to SQL injection
3. The SQL Server user that your web application authenticates as must have SELECT and UPDATE access to the sysobjects table

Notice that nowhere in that list is IIS mentioned. In addition, plenty of shops meet the first criterion above, without meeting either of the other two. Unfortunately it's all too common that web applications are configured to use the "sa" account, or some functionally-equivalent clone thereof.

If your web application can query dbo.sysobjects and get anything other than "Server: Msg 229, Level 14, State 5, Line 1" in response, it's time to hire an additional DBA. If your web application allows random queries to be passed into SQL Server in the first place, it's time to hire an additional developer. In either case, make "security" a bullet-point on the job posting.

Re:This is NOT an IIS problem

[Anonymous Coward]

Mod parent up. Way up. In a thread with so much misinformation it makes my head spin, here is a concise explanation of the real problem.

Attacks logged are from China

[Anonymous Coward]

I have monitored these attacks on my sites since the second week of April 2008. It should be noted that ALL of the logged attacks IP addresses resolve to CHINA, mostly in the Beijing area... Why is nobody discussing this aspect of the hack?

SQL Server is ridiculously vulnerable

[butlerm]

The problem here is that MS SQL Server supports multiple statements in the same prepare / execute block in an unsafe manner. Just insert a semicolon and off you go.

The safe way to support multiple statement execution ("query stacking") is with something like the block syntax of Oracle. Given a single unchecked entry field, the SQL Server syntax is trivially exploitable do anything the attacker wants.

Please code review

[atomic777]

$response = "Hibernate has its benefits, but you don't need to rework your whole data access layer to get protection from SQL injection, ";

$solution = "just use prepared statements " ;

$_GET = "and smack (with a blunt object) any developer that concatenates untrusted input during code review ";

echo $response + $solution + $_GET;

Right, but...

[Jeff Molby]

...it's weak idiot-proofing. Strong idiot-proofing makes it so the problem is never even encountered.

NoScript saves the world :|

[dgun]

and is easily defeated by the end user with Firefox and "NoScript".

Oddly placed plug, lol. It kinds of stands out. So would this problem also be defeated with people running IE with javasscript disabled? Firefox is my browser of choice, I just thought this was a weird place to drop a 'NoScript' advertisement.

Don't need Hibernate per se

[daBass]

Although I like OR-mapping frameworks, you don't need one to avoid SQL insertions. Plain old PreparedStatement in JDBC will do that job just fine also.

Solutions

[tjstork]

Everyone keeps looking at this like it is an attack on IIS and SQL Server, but the actual body of code attacked is actually JavaScript. If the client doesn't have Javascript, then nothing bad happens - with this sort of attack.

Now, there are other attacks that rely on SQL injection... and the prevention is arguably worse than the disease. These days, a lot of DBAs will say that best practice in SQL Server or any sort of database is often said to be against using SQL directly, and wrapping everything in stored procedures, but, this has huge disadvantages.

It's more expensive - you add another layer between you and your data. It all but removes ad-hoc querying off of user pages. Granted, most developers won't have it in them to build up WHERE clauses, joins and connectors into some sort of a point and shoot form, but, why are we giving that up so that we can write two hundred stored procedures instead? This sort of security costs way too much. What's the point of having SELECT if you can't use it, especially when ISAMS already give you basic CRUD out of the box.

To stop SQL injection, all you really need are two things. First is that you have a way to disable writes at the query call level, and the second is to merely scrub quotes at input from a form.

If you disable writes at the call level, one could do something like:

query( statement, false ); and the engine would not allow -any- write no matter what was in statement. At this point, the very worst that a SQL injection attack could do would be to try and get additional information from your database, but it couldn't change anything. queries for updating and input would be more complicated, for sure, but the intent here is to more safely allow dynamic sql for querying.

scrubbing quotes is just common sense.

Google to the resc... er, whoops.

[Anonymous Coward]

I just Googled "well-established security practices for handling database input". First 30 hits are blogrolls about this story. After three pages of results most searchers lose interest, so I won't be getting a handy checklist until some smart programmer with better bookmarks than me replies to this comment with a decent article on a website that hopefully hasn't been compromised by this attack.

If you read all that, congratulations, most /.'ers lose interest after 30 words without punctuation.

Re:Google to the resc... er, whoops.

[Skrynesaver]

Who ever thought they'd hear the line, let me show you how I do it in Perl, that'll explain everything, but hey who said it was a write only language ;)

use HTML::Entities ();
use CGI qw/:standard/;
foreach $param ( param() ) {
$value = HTML::Entities::decode( param($param) );# Remove url encoded sneakiness
$value =~ s/[^a-zA-Z0-9 ,-]//go; # Strip invalid characters
param($param,$value); # reset the parameters value for the rest of the script.
}

This IS an SQL problem (in part)

[Skapare]

I agree that this is not an IIS problem. IIS is just a convenient target. And it may also be the case that users of IIS are less likely to do proper data sanitation than those who can't use IIS. But I would argue that SQL is a major target of blame.

Long long ago when I first learned of SQL, it was described as a command line language which would allow people to do innovative database searches. I saw several examples of such. The lecturer was even typing them in manually. It sure looked like a really great tool, both for the database administrator, as well as for people that needed to work directly with the data in relational databases. What never came across at that point in time was that using SQL was the primary way for programs to access the database.

Later I found out the hard way that this was necessary when a program I was developing needed to get some data from the database. I almost lost my lunch. It was bad enough that user input data might be used to open a file by name. But at least reading and writing of files was done specifically by calls inside my program and didn't involve constructing strings to be parsed and interpreted somewhere. Now with the need to access something in an SQL database, I immediately saw a huge problem.

I was working with the DBA on this aspect of my project. He told me what SQL I needed to use for what I wanted access to (I didn't know any SQL at that time). I just needed to insert certain pieces of data describing what I wanted at specific places in the (rather largish) SQL commands he gave me. I could see the exposure immediately, as well as some solutions. So I just mentioned something like "I'll need to filter this so I don't have quotes in the string". He asked why. I asked "Won't a quote in the data look like the quote that ends the string?" He replied, "I guess so, but then you'd just have a syntax error". "What if someone inserts valid SQL after that which ends in a quote to start a new string?" And his reply "Why would anyone want to do that?". I just shook my head and proceeded to write code that removed everything but letters and numbers.

Had relational databases also had a means for more direct access (turns out some do) that doesn't involve any SQL, they might be safer. But what was really needed as a part of any database access library is specific code to be used to construct the SQL command line that applies all the necessary data sanitation. Even to this day I don't know if a quoted string in SQL can have a quote embedded with an escape (I never used SQL enough to need to know). If it can, then the calls to insert a quoted string in the SQL command being built should escape quotes in the C string being passed to it. If not, it should just remove them (and then you can't use quotes in a string for anything).

Maybe I should not have been so amazed at the lack of security thinking back in the 1990's when this took place. I was amazed, nevertheless. But I can see how back when they developed these interfaces, they would not have thought about all this at all. Based on all the security problems I have seen since, being amazed back then was clearly out of place. And it was a web application I was developing. Hopefully, they aren't running it anymore. But if they are, it's probably a whole lot safer than others developed by other people in that era (and, unfortunately, even those developed today).

Yes, programmers of the web applications are significantly to blame. But SQL should have included the tools to make constructing safe SQL from unsafe tainted data work in a safe way ... and made those tools the standard way to do things (not unsafe tools like sprintf from the C library, or similar from languages used today).

In summary, my blame (mostly) points at SQL itself.

The problem is with the developers...

[Anonymous Coward]

... who failed follow well-established security practices...

Yeah, like letting OS-es never meant to be networked out on the Internet

MS SQL Server is particularly vulnerable

[butlerm]

Microsoft SQL Server is particularly vulnerable to SQL injection in a way that most other databases aren't. The problem is multiple statement execution just by inserting semicolons.

Catalog access isn't much of a vulnerability if an attacker cannot trivially execute SQL ad lib. with a single unchecked parameter.

Re:MS SQL Server is particularly vulnerable

[Allador]

Microsoft SQL Server is particularly vulnerable to SQL injection in a way that most other databases aren't. The problem is multiple statement execution just by inserting semicolons. That is incorrect.

Most mainstream databases allow you to do this. Oracle and MySQL off the top of my head that I've personally done this on.

Some db adapter libraries (like one of the real simple ones in PHP for MySQL) dont let both statements get through and/or throw an error, and/or cant handle multiple result sets.

But keep in mind, an attack like this doesnt require both statements to be run in the same batch or in the same transaction, since there's no connection between the two and no result set from the second command.

This simplifies the requirements. Some DB libraries dont allow multiple result sets to come back, but the vast majority allow multiple commands to be sent.

Catalog access isn't much of a vulnerability if an attacker cannot trivially execute SQL ad lib. with a single unchecked parameter. /quote.

What allows an attacker to trivially execute SQL isnt anything to do with MSSQL, but with the app design that is concatenating sql strings and then passing them unchecked to the db.

This exact problem is hugely rampant on PHP/MySQL sites.

When doing casual pen-testing at prior jobs, I've made this sort of attack work against Oracle WebDB, PHP/MySQL, ASP/MSSQL, and Java/Oracle.

Re:MS SQL Server is particularly vulnerable

[Allador]

Whoops, unclosed quote tag there.

The last three paragraphs are mine, responding to the quoted fourth-from-last.

Re:MS SQL Server is particularly vulnerable

[butlerm]

My point is that with Oracle, DB2, PostgreSQL one has to construct a compound SQL statement as a block starting with BEGIN and terminating with an END. That makes it very difficult to inject a second SQL statement. MS SQL does not have this requirement, hence the (much increased) vulnerability.

That said, I wouldn't be completely surprised if some Microsoft ADO drivers for the above databases add the same "feature" in the name of SQL Server compatibility. As for myself, I avoid Microsoft server technologies like the plague.

Microsoft is at fault here

[butlerm]

That is not correct. MS SQL Server is vulnerable in a way that no other database that I am aware of (Sybase perhaps) due to the way it constructs compound statements.

Oracle is not vulnerable to this type of attack, nor is DB2, nor PostgreSQL. Some databases, like MySQL, are apparently only vulnerable when using a Microsoft ADO driver - same design mistake: support for compound statements without requiring block structure (BEGIN / END) allows trivial injection of arbitrary SQL.

Re:Microsoft is at fault here

[Allador]

This is incorrect.

I've personally made successful sql injection attacks (in-house pen testing, not black hatting) of this sort against a variety of other platforms that had nothing to do with Microsoft, including Oracle and MySQL.

I'm not going to go into details here as I already responded in more detail to another of your posts.

Re:Microsoft is at fault here

[butlerm]

Please explain how you would exploit the following purposely vulnerable example in Oracle, assuming you had arbitrary control over the employee_nbr variable:

string employee_nbr;

sql = "SELECT * FROM EMPLOYEE WHERE EMPLOYEE_ID = " + employee_nbr;
Execute(sql);

In MS SQL you could submit "1; DELETE FROM EMPLOYEE" and it would be game over. The same thing doesn't work in Oracle. The best you might do is submit "1 OR 1 = 1" and get information you weren't supposed to have.

Dynamic SQL was once an anomaly

[butlerm]

Twenty or so years ago, using dynamically generated SQL was expensive, slow, and hard to program. The vast majority of SQL applications were written with SQL statically embedded in C, FORTRAN, or COBOL dialects that had to be translated to the base language using a precompiler.

Parameters were bound by name to host language variables, and the precompiler handled the mapping to the underlying database library. Much more secure than dynamic SQL without bound parameters.

Of course as computers got faster, the penalty for not binding parameters was reduced. Application language developers got lazy and added SQL APIs without any way to bind parameters at all. ColdFusion was this way for years, for example. The first time I saw it I was shocked - not so much for security reasons, as for the low efficiency the lack of such support implied.

In short - barring a few semantically impaired languages - it has always been possible (and once was the far and away predominant practice) to bind typed parameters to SQL statements and avoid potential injection vulnerabilities completely.

Sometimes I wish there was an "uninformative" mod.

[ArsenneLupin]

Most mainstream databases allow you to do this. Oracle and MySQL off the top of my head that I've personally done this on. Maybe there are other databases than MS SQL server that do allow multiple statements in one API call (JDBC, ODBC, ...), but Oracle and MySQL certainly aren't. In Oracle and MySQL you'll get a syntax error if you try.

Of course, in a script you (obviously) can put multiple statements, but a script is not what the webapp (written in ASP or PHP) uses when communicating with the DB back end.

So, if you have an ASP front-end with an Oracle or Mysql back end, you are not vulnerable to this kind of SQL injection, but you might be vulnerable to other kinds, which don't involve multiple statement execution. However most generic cookbooks or exploits do need the multiple statement vulnerability.

SQL Injection is Microsoft's problem?

[ArmyOfAardvarks]

How about using some stored procedures and character filtering? I really fail to see how this problem has anything to do with Microsoft. If your code sucks, SQL injection can be done on pretty much any platform that uses a database.

Re:Sometimes I wish there was an "uninformative" m

[jotok]

Um...are you sure?
Not doubting you, but I'm pretty sure if I run something like

show tables;describe foo;drop table bar;

Then it will execute with no problems. Maybe I'm just not savvy enough with MySQL to understand what you're saying.

I do know that, for instance, this specific injection attack uses cursoring...sure, in MySQL cursoring is handled differently, that doesn't make Microsoft responsible for this "vulnerability." It's still the fault of the ASP developer for not sanitizing his inputs.

Re:Sometimes I wish there was an "uninformative" m

[ArsenneLupin]

Maybe I'm just not savvy enough with MySQL to understand what you're saying. Indeed, you don't understand what I was saying. Or maybe you simply didn't read far enough:

Of course, in a script you (obviously) can put multiple statements, but a script is not what the webapp (written in ASP or PHP) uses when communicating with the DB back end. ...

I do know that, for instance, this specific injection attack uses cursoring...sure, in MySQL cursoring is handled differently, that doesn't make Microsoft responsible for this "vulnerability." It's still the fault of the ASP developer for not sanitizing his inputs. Actually, the issue here is that with Microsoft, it is possible to write generic attacks such as the above. With other backends (and frontends), you have to tailor the attack to the specific app, and very often it is just not possible. And where it is possible, it often involves a second bug in addition to SQL injection.

Multiple Queries

[Liquidrage]

Are not the problem. That is a feature and one that is used very often as ADO also supports multiple recordsets.

The solution is to use these tools properly. For years SP's were the norm for people doing database development. Then the younger generation of coders really took to crud generators and very often I see people totally arguing against SP's. Mostly I chalk this up to lack of experience. I really don't care which one is faster, having all my code that directly references database object at the database level is just a "no duh" right way approch.

SP's with parameters (also supported by ADO) is the way to go. Either .NET or classic. If people want to use their crud generators and whatnot fine, but please abstract your database code back into the database. It's lazy not to do so.

they get what they deserve

[gsgleason]

If the coder of the site doesn't thoroughly filter their data passed to the query, they deserve to be h4x0red.

Simple to avoid

[hlavac]

Code is vulnerable because app tries to create a whole SQL command string with parameters in it dynamically and passes it to SQL driver to execute. Not only is it slow but you also easily forget to escape the parameters. It is better to use the bound parameters method instead, having static SQL command string (with placeholders for parameters) and bound parameters passed along it. In that case, the SQL is static, does not contain any externally provided data and can be better optimized by the server, and you avoid any escaping issues and cost alltogether. For example, in JDBC you would use PreparedStatement. Of course, some databases/SQL APIs do not support it ;(

Re:Shameless ORM Bashing

[Rary]

As a complete aside, I don't believe hibernate sanitizes inputs for you, so it's still possible to perform injection attacks on it

Hibernate guards against SQL Injection by using PreparedStatements with bind variables.

Firefox & NoScript

[duerra]

Sorry, I think I missed something. What exactly does Firefox and NoScript have to do with this, again?

Re: SQL Server vulnerability

[Randolpho]

I have to say this is the most succinct explanation of why SQL Server is specifically vulnerable to the attack. It's certainly something for Microsoft to look at the next time they look into modifying T-SQL.

I do not, however, think this rises to the level of actually being able to blame Microsoft for the attack. The fault there lies 100% on the shoulders of programmers who did not use the tools available to them to eliminate SQL injection.

The structure of T-SQL did allow the hackers to add the javascript to every text field in the database, yes. But the fact that they were able to allow javascript to *any* text field is entirely the fault of the site programmers.

Re:

[clint999]

Ignoring corporate spin-doctoring there seems to be plenty of blame to go around.