The real danger

The greatest danger to the west isn't Osama Bin Laden, it's Little Bobby Tables.

Thats it then for the internet.

@Christoph xkcd reference ftw. A sort of poor mans worm but still fairly complex anybody have any suggestions on how to encourage/beat into submission these web developers to stop being so silly. Anything this side of capital punishment seems not to work.

W3C

If they are not coding to code they shouldn't be available to ISPs, it is as simple as that. Why have ISPs been so lax so long?

If they sorted out all the spam and all the botnets we could clear the decks for unrestricted file transfers from You Tube. Think of all the cats we could be watching.

All hail Bobby Tables

I said it here already, and was called stupid for giving my opinion, but it is weird that most databases engine do not already include an option making this impossible.

Apparently, H2 has an option for this, called "disabling literals". If you are a professional making an important web site, you check the option, and yes, your code is slightly harder to read. That's it.

The question is, why is there only ONE database engine with this option? I've seen an Oracle database auto-replicating on five different servers. Is this option harder to implement? Or maybe they did not have the resources to do it, because, y'know, Oracle is such a small start-up and everything?

I guess the web developers, the coders, and the database programmers have been passing each other the buck for years now...

Paris, because she knows something about getting passed from one person to the other...

No excuses!

PHP and most other frameworks have various ways oif diosabling SQl injection attacks.

In PHP you can set an SQL escape global setting and if that doesnt work there are numerous functions to clean up entered strings.

Failing that ORACLE and most other databases supply an SQL escape function/option.

Failing that how hard is s/;/\\;/g s/'/''/g ?

I am afraid this one is totaly down to developers not understanding the consequences of thier lazy coding styles.

Personaly I always "prepare" and "bind" which are bulletproof and perform better anyway.

ratfox

I'm curious about how you plan to prevent the server executing valid sql that is passed into it. You could do it by seperating raw sql from stored procs (at least that is one common way) - the only thing then to make sure is that the user that the application connects as only has the rights to exec the procs, not rights on any other objects.

Most rdms have this, but the chances are that if sql injection is going to get anywhere the lazy devs have the app user running with massively escalated rights in the database - more often than you might believe they are running as sysadmin level.

The point is that there are best practices to minimise the risks, and they are not being followed. Any more clever tricks you add to the best practice list will almost certainly also be ignored.

go to the source

"The point is that there are best practices to minimise the risks, and they are not being followed. Any more clever tricks you add to the best practice list will almost certainly also be ignored."

yes I agree with this. I think that much more responsibility must go to the developers of the databasetools. The reason is that those tools are marketed to relative IT novices with "anyone can now make a online database using our "easy to use tools". This means that the type of development that 20 years ago required competence in networked database systems and associated security issues is now done by people who have very limited competences in this area. Is this a problem? Well it should not be. When it comes to areas of technological development it is common that as technology is developed the demand on the users of this technology in understanding the technical aspects of it goes down. This is not a problem as long as it is remembered that while the user of a car has to know how to drive the car she does not have to be an engineer to secure the car. When it comes to design of databases - the responsibility for what the database does should be the web designers - the responsibility for much of the underlying security issues must be put on the designers of the database tool itself. Ofcourse this will not solve many common security issues - but it should solve many important security flaws that today are seen more often than not.

@AC - Language Bashing

I dont think its a problem inherent with using ASP, as the article makes no mention of .net its likely that ASP "classic" is the main target, and i would hazard a guess that one of the main searched for pages to inject SQL into is from the OS Snitz Forum project, which has numerous published vulerabilites with no update since 2006.

The main problem here is with lazy developers, a language (and that is pushing the deffinition tbh in ASP's case) that hasnt been updated in 7 years (all ASP dev at MS stopped with the release of ASP.net) coupled with improper practice being followed.

Although this is most deffintatly not a ASP exclusive problem. any web facing system with inadequet input filtration and screening is vulnerable. ASP's weakeness here is that virtually all encryption and input filtration is left to the developer to impliment. At least PHP has magic quotes and built in md5 but then php5 is 2 versions ahead of the last release of ASP (3.0) but significantly behind ASP.net 2.0 and 3.5 imho. However it is possible to construct parameter based sql queries in ASP which can go a long way to stopping this sort of thing, and is a lot better than php's 'sprintf' function, as you can kind of impose data typing onto the input using ADO and db column types.

Finally several security features are often disabled or unaccessable to a developer when using a shared hosting environment, stuff like custom error pages, so that db struture cannot be gleened from an ADO error or having the ms access db being accessible from the web, in my experiance often with directory browsing enabled as well :(, that really is the responsibility of the ISP in those cases.

@Name

There is nothing wrong with IIS, any specific breed of SQL or language used to script the website.

All (and I mean *all*) SQL injection errors originate in application passing not satinized user input to SQL, and *all* platforms with database backends *do* provide functionality to do both : pass not satinized input to SQL or satinize it beforehand.

It is "web developer" choice not to satinize user input, and it does not surprise me, as many of them are as ignorant as it goes. The question whether "web developer" knowing only PHP, HTML and basics of SQL is real programmer had not been answered yet.

Disabling it on the databases - harder than you'd think

Because then we would not be able to do dynamic SQL, and that's a tool I could not do without.

Just use parameter binding in the web app - every book on programming web apps says this. Unless, of course, the IIS examples don't.

Developers or employers?

I've seen some horrible programming mistakes made by people who have just come off Java training classes then being given the job of writing J2EE applications to the best of their ability.

Surely, it's down the the employers to ensure that their coders have adequate training and adhere to programming standards that they publish. (And possibly enforce by sensible use of tools like JUnit and Cactus)

As usual, if you think training/education is expensive, try ignorance.

I meant "sanitised", of course

stupid spelling mistake. Mine's the one without dictionary in the pocket.

IIS vs LINUX servers

are there still people spassing money on MS Servers??

Weren't the last large exploits all based around a) MS desktops b) MS servers?

And then you still have to pay for the priviledge??

Human idiocy/corruptibility is infinite!

Use Linux - be free